Licence conditions for controlled computing exports under OFAC: in practice

A technology exporter holds a specific licence for a cross-border computing shipment. The licence was hard-won. The conditions attached to it – end-use certificates, post-shipment verifications, reporting windows – were read once at the time of grant and then largely forgotten. A routine compliance audit surfaces the problem: several conditions have been breached, a shipment has moved, and OFAC is now in contact. What happens next, and what could have prevented it?

Licence conditions for controlled computing exports under an OFAC-specific licence are legally binding obligations, not guidance notes. A breach of a condition is a sanctions violation in its own right, enforceable on a strict-liability basis under IEEPA, regardless of whether the underlying transaction was lawful when licensed. As of January 2026, enforcement interest in computing-related licence conditions has intensified, particularly where foreign direct product considerations or advanced-technology end-uses are involved.

This case comment walks through a representative matter from initial discovery to resolution, identifies the conditions most commonly breached, draws the cross-regime comparison that matters for exporters subject to both OFAC and BIS, and sets out the lessons a similarly placed business should act on today.

The situation: a licence granted, conditions unread

OFAC-specific licences for controlled computing exports are granted on a case-by-case basis and carry individually tailored conditions. These conditions form part of the legal authorisation itself, and the licence is valid only when every condition is met in full.

In the matter we describe here, a technology manufacturer held a specific licence authorising the export of a defined category of computing equipment to a particular end-user. The licence had been obtained after a substantive application process. Counsel had advised on the core prohibition; the compliance team had recorded the licence number and filed the authorisation. That was where structured oversight stopped.

The conditions on the face of the licence required, among other things, that the exporter obtain signed end-use assurances from the named end-user before each shipment, that it retain those assurances for five years, and that it report to OFAC within a defined window if it had reason to believe the goods had been diverted or re-exported outside the authorised scope. A secondary condition required the exporter to notify OFAC before any change in the end-user's ownership structure.

Three shipments moved over a period of several months. No end-use assurances were collected for two of them. The retention obligation was therefore moot for those shipments; there was nothing to retain. On the third shipment, an assurance was collected but post-dated. When the end-user's parent company was restructured, no notification was given to OFAC. The conditions, taken together, had been substantially breached.

The audit that surfaced this was not triggered by a regulatory inquiry. It was a scheduled internal review of the export licensing portfolio. That timing mattered. It is far better to self-identify a condition breach than to learn of it through an enforcement notice.

The legal question: what does a breach of licence conditions actually mean?

A condition breach on an OFAC-specific licence is not a procedural irregularity. It is a substantive violation of the authorisation under which the export proceeded.

OFAC's authority under IEEPA is broad. Civil liability attaches on a strict-liability basis: the regulator does not need to prove that the exporter knew the conditions had been breached, or intended to breach them. The relevant question is whether a prohibited act occurred without valid authorisation – and an authorisation is not valid where conditions have not been met. In this matter, the two shipments for which end-use assurances were missing had, in effect, moved without full authorisation.

The record-keeping obligation is similarly strict. Sanctions records must be maintained for five years, and the failure to retain a required document is itself a breach, separate from the underlying transactional conduct. Where the document never existed – because the assurance was never collected – the breach is both the absence of the document and the absence of the substantive step the document was meant to record.

OFAC's Enforcement Guidelines distinguish between egregious and non-egregious cases, and between matters where a voluntary self-disclosure (VSD – a proactive report of a potential violation filed before an investigation commences) has been submitted and matters where it has not. The distinction is material to penalty exposure. In non-egregious cases with a VSD, the guidelines direct a substantially reduced base penalty. In egregious cases, even with a VSD, the reduction is more limited.

How did the conditions get breached without anyone noticing? In our experience, the answer is almost always the same: the compliance programme treated licence conditions as a post-application matter rather than a standing obligation integrated into the shipment workflow. The licence sits in a folder. The conditions are not mapped to the shipping process. No one checks the file before each shipment goes out.

The cross-regime dimension: where OFAC and BIS interact on computing exports

Any exporter of controlled computing equipment operates under two parallel regimes simultaneously. OFAC governs financial sanctions and the prohibitions on dealing with designated persons; BIS governs the classification and physical movement of items subject to the Export Administration Regulations (the EAR – the US rules governing items on the Commerce Control List). A licence from one agency does not substitute for compliance with the other.

In the matter described here, the computing equipment also carried an ECCN (Export Control Classification Number – the identifier that places an item on the Commerce Control List and defines the controls that apply). The BIS licensing and end-use obligations ran in parallel with the OFAC conditions. Some of the end-use documentation required by OFAC mirrored what BIS required; some was additional. The practical lesson is that a combined checklist – covering both agencies' conditions in a single workflow – is far more reliable than two separate filing systems that neither team maintains consistently.

BIS maintains the Entity List and the Denied Persons List; dealings with parties on either require a licence or are prohibited outright. OFAC maintains the SDN List (the list of Specially Designated Nationals and blocked persons). The lists are separately maintained, but a counterparty can appear on more than one of them. The 50 percent rule – OFAC's rule treating entities owned 50 percent or more in the aggregate by blocked persons as themselves blocked – applies independently of any Entity List analysis. Both must be run.

The EAR's Foreign Direct Product rules can bring foreign-produced items within US jurisdiction where they are the direct product of controlled US technology or software. In a computing context, this is not a theoretical concern. Where a licensed export is later incorporated into a foreign-manufactured product and re-exported, the original exporter's OFAC conditions may have anticipated this scenario – and may require notification or prior consent. We regularly advise exporters who discover, only after a re-export occurs, that their OFAC licence conditions addressed exactly that situation.

For exporters subject to UK or EU rules as well, the overlap becomes more complex still. The UK's ECJU administers export licensing for controlled goods, and OFSI administers financial sanctions with its own licensing regime under SAMLA and the relevant thematic regulations. The UK ownership-and-control test operates differently from OFAC's 50 percent rule: it looks at control as well as formal ownership, and a non-listed entity can be caught through a listed person's practical ability to direct it. An exporter subject to both US and UK obligations cannot satisfy OFAC conditions and assume the UK position is covered; the two regimes must be worked through separately, and where they diverge, the stricter prohibition governs.

EU dual-use controls under the recast Dual-Use Regulation add a further layer for EU-based exporters or transactions with an EU nexus. The EU asset-freeze prohibitions extend to making funds or economic resources available – directly or indirectly – to or for the benefit of listed persons, which in a computing export context can reach technical assistance and software provisioning as well as hardware.

How was the matter resolved?

The primary decision facing the exporter after audit was whether to file a voluntary self-disclosure with OFAC, and on what timeline. That decision had to be made quickly: the window between self-identification and a potential regulatory inquiry closing narrows fast, and the mitigating value of a VSD depends on it being genuinely voluntary – filed before the regulator is already aware of the issue.

The team's first step was to scope the violations precisely. That meant reconstructing the shipment history, retrieving every document that existed, identifying every gap, and assessing whether any of the conditions not met rose to the level of an egregious case under the Enforcement Guidelines. An egregious case – typically one involving wilful or reckless conduct, a senior management failure, or a sophisticated compliance programme that was deliberately bypassed – attracts a substantially higher penalty ceiling. The facts here did not suggest wilfulness. The breach was a compliance failure: conditions were misunderstood and oversight was absent. That framing shaped both the VSD narrative and the remediation plan.

A VSD was submitted. It set out the violations chronologically, explained the root cause, identified the affected shipments, and presented a detailed remediation programme. The remediation plan included redesigning the licence condition monitoring process, embedding end-use assurance collection as a mandatory step in the shipping workflow, implementing a licence condition tracker reviewed at each shipment, and training the responsible teams. Records going forward would be maintained in a form and for a period consistent with the five-year retention obligation.

The matter proceeded through OFAC's review process. Voluntary self-disclosure is a recognised mitigating factor under OFAC's Enforcement Guidelines, and that, combined with the absence of any evidence of wilfulness or harm to the sanctions programme's objectives, shaped the resolution. No public penalty notice was issued. The matter was resolved through the administrative process.

We have acted for exporters in comparable situations where the timeline from VSD submission to resolution extended across many months. That is not unusual. The process requires patience, continued cooperation with the regulator's queries, and ongoing implementation of the remediation commitments made in the disclosure itself. Abandoning the remediation plan partway through the review period is one of the more damaging steps an exporter can take.

Risk flags for controlled computing exporters

Licence conditions for controlled computing exports under OFAC carry specific and recurring risk patterns. The following are those we encounter most often in practice.

End-use assurances collected after the fact. The condition almost invariably requires a signed assurance before the shipment departs. An assurance collected after delivery does not satisfy the pre-shipment condition, even if the end-use itself was lawful. The sequencing is part of the obligation.

Change in end-user ownership. Licences granted to a named end-user may lapse or require fresh notification if the ownership structure of that end-user changes materially. The 50 percent rule can convert a previously unproblematic end-user into a blocked entity overnight if a new investor enters the capital structure. A change in ownership that would be commercially unremarkable in another context can be a reportable event under an OFAC licence condition – and a failure to report it a separate violation.

Diversion or re-export outside authorised scope. A specific licence authorises a defined transaction: specified goods, specified end-user, specified territory. Re-export beyond that scope is not covered. Where the licence conditions require the exporter to report knowledge or reasonable suspicion of diversion, that obligation is active from the moment goods leave the exporter's control. "We didn't know" is not a defence if there were red flags the exporter did not investigate.

Record-keeping gaps. The five-year retention obligation applies to all sanctions-related records, including licence applications, approvals, conditions, end-use documentation, correspondence with OFAC, and any report filed. A gap in the record is itself a breach. Where the document gap coincides with a shipment gap, the risk compounds.

Assuming a general licence covers the position. The myth that a general licence (a standing authorisation permitting a defined category of transactions without a separate application) covers the full scope of a controlled computing export is a recurring compliance failure. General licences for computing contexts are often narrow: they may cover a specific category of hardware or a specific territory, and they carry their own conditions. Relying on a general licence without reading its scope and conditions is not materially different from proceeding without a licence at all, if the transaction falls outside what the general licence actually permits.

Does your team know which general licences apply to your product line, and have the conditions been read and tracked? That single question, posed honestly to the compliance function, surfaces a significant proportion of the risks we see.

When to involve counsel, and what happens if you wait

The correct moment to involve sanctions and export-control counsel is before the licence application is submitted, not after the conditions have been breached. That is the point at which the conditions can be read carefully, integrated into the shipment workflow, and, where appropriate, negotiated with OFAC during the application process – because conditions are not always fixed, and the scope of what is requested can be framed to minimise condition-management burden.

Where conditions have already been breached, the calculation changes. Time is the variable that matters most. The longer the gap between identifying a breach and acting on it, the narrower the options. A VSD filed promptly preserves the mitigating value that the Enforcement Guidelines attach to it. A VSD filed after a regulatory inquiry has already commenced is no longer genuinely voluntary, and OFAC treats it accordingly.

In our cross-border practice, we regularly see situations where exporters identify a condition breach, take several weeks to debate internally whether to disclose, and then submit a VSD that is effectively concurrent with an OFAC inquiry. That sequence forfeits much of the benefit that early disclosure would have secured.

The question exporters ask most often at this stage is whether disclosure will make the position worse. The honest answer is: occasionally, a VSD surfaces a pattern that a regulator would not otherwise have found. More often, the alternative – non-disclosure and a subsequent regulator-led enforcement action – produces a materially worse outcome on penalty, and a reputational one as well, since regulator-initiated enforcement is more likely to result in a public notice.

Counsel's role at the post-breach stage is threefold: to scope the violations accurately, to frame the VSD in a way that is accurate, complete, and contextualised, and to build a remediation plan that the regulator will accept as genuine. Where BIS conditions are also in issue – as they frequently are in a computing context – the VSD strategy needs to account for both agencies, and the sequencing of disclosures requires careful thought.

For a confidential review of a potential licence condition breach or a dual-agency exposure, contact Calder & Vance at info@caldervance.com.

The lesson for exporters managing computing licences

The lesson from this matter is not that the licensing process failed. The licence was correctly obtained. The failure was in what came after: a compliance programme that treated licence grant as the end of the process, rather than the beginning of an ongoing obligation.

A specific licence for controlled computing exports is, in practice, a contract with the regulator. It defines what is permitted, under what conditions, with what documentation, and within what time bounds. Every shipment against that licence should be preceded by a review of the conditions: are the required documents in place, is the end-user still who they were at the time of the application, has anything changed in the ownership structure, and does the destination remain within the authorised scope?

That review takes minutes if it is embedded in the workflow. It takes months to reconstruct after the fact, when the question is no longer theoretical and the regulator is asking questions. Exporters who treat licence conditions as a compliance checklist to be run at every shipment, rather than a box ticked at the time of grant, are not doing more compliance work. They are doing the right amount in the right order.

One further point deserves emphasis: the assumption that a general licence resolves the position. We encounter this regularly, and it is one of the most costly myths in export licensing practice. General licences are narrow instruments. They are designed to cover defined and relatively predictable categories of transaction, and their conditions are often just as detailed as those on a specific licence. An exporter who has not read the full text of every general licence they rely on – and mapped those conditions to their product line and routing – is carrying undisclosed risk.

The cross-regime dimension amplifies this. A business that holds an OFAC-specific licence and relies on a BIS licence exception for the same goods has two separate condition sets running simultaneously. The OFAC conditions do not govern BIS compliance, and vice versa. Our practice covers both, and the most effective compliance programmes we work with maintain a single integrated licence condition register that tracks obligations across agencies in one place, allocated by shipment.

For more detail on the service architecture behind this type of matter, see our OFAC computing licence conditions advisory service. For a step-by-step guide to obtaining and managing BIS and EAR licences for computing exports, see our guide to BIS and EAR licence conditions for computing exports. Further analysis of the OFAC licensing process specifically is available in our OFAC licence conditions guide.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@caldervance.com.