How to control remote access to computing power under OFAC

A software business in Germany grants an engineer in a third country remote access to a high-performance computing cluster hosted on a US cloud platform. The engineer runs a simulation. The business assumes that because no physical goods crossed a border, no export-control or sanctions obligation arose. That assumption is wrong – and the consequences of getting it wrong can be severe.

Under OFAC's sanctions programmes and the Export Administration Regulations (the EAR, administered by BIS), remote access to controlled computing technology constitutes a deemed export or a sanctionable transfer where the recipient is in a comprehensively sanctioned jurisdiction or is a blocked person. The cloud and remote-access technology controls regime treats the release of access credentials, processing capacity, or controlled technical data to a foreign person as equivalent to a physical transfer. The analysis turns first on who the recipient is, then on where they are, and then on what they can do with the access granted.

This guide sets out the decision sequence a compliance team should follow, the points where the analysis branches, the cross-regime considerations that US-centric assessments tend to miss, and the risk flags that should bring counsel into the room.

Is the recipient a blocked person or in a comprehensively sanctioned jurisdiction?

This is the first branch in the decision tree, and it must be resolved before any other analysis begins. If the answer is yes, the transaction is prohibited regardless of the technology involved, and no further classification analysis is required to reach that conclusion.

OFAC administers two distinct types of sanctions programme. List-based programmes prohibit dealings with persons on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons) wherever in the world they are located. Comprehensive or territorial programmes prohibit a broader range of transactions with entire jurisdictions, subject to limited exceptions. A remote-access arrangement can trigger either type or both simultaneously.

Screening the end user against the SDN List is a necessary first step. It is not a sufficient one. The 50 percent rule (OFAC's rule treating entities owned 50 percent or more by one or more blocked persons as themselves blocked, directly or indirectly in the aggregate) means that a corporate entity not named on any list may nonetheless be blocked. A cloud-services provider granting access to a company that appears clean on its face may be transacting with a blocked entity if the beneficial-ownership layer has not been examined. In our experience, this is the gap that routine automated screening most commonly leaves open.

Comprehensive programme restrictions apply to the territory and to persons ordinarily resident or operating within it. Remote access from a device physically located within a comprehensively sanctioned jurisdiction generally falls within the prohibition, even when the request is routed through a VPN or an intermediate server. The physical location of the endpoint matters, not the technical appearance of the connection.

Does the technology qualify as a controlled item under the EAR, and does a deemed-export obligation arise?

Where the recipient is not a blocked person and the territory is not comprehensively sanctioned, the analysis shifts to whether the technology being accessed is subject to the EAR and, if so, whether releasing that access to a foreign person constitutes a controlled transfer.

A deemed export occurs when controlled technology or source code is released to a foreign person within the United States. The EAR extends that concept: making controlled computing capacity or the technical parameters needed to use it available to a foreign person – wherever that person is physically located – can constitute a deemed export or a deemed re-export depending on the person's nationality and the nature of the technology.

Items are classified by an ECCN (Export Control Classification Number under the US Commerce Control List). Items subject to the EAR but not listed on the CCL receive an EAR99 designation. Advanced computing hardware and the software required to operate it commonly carries classification with controls linked to national security, anti-terrorism, or regional stability. Access to that capacity – even remote, even transient – falls within the licence requirement if the foreign person's nationality or location triggers a control.

The Foreign Direct Product rules (FDP rules) extend EAR jurisdiction extraterritorially. A foreign-manufactured system that is itself the direct product of controlled US technology or software, or that is produced by a plant that is the direct product of such technology, can be brought within EAR jurisdiction. A cloud platform operated outside the United States that incorporates controlled US semiconductors or was built using controlled US software development tools may therefore be subject to the EAR, and granting access to controlled workloads running on it may trigger a US licence requirement even for non-US operators.

Has your legal team examined the FDP exposure of the infrastructure, not just the classification of the workload itself?

If a controlled item is involved, which licence exception or authorisation applies – and where does the analysis branch?

Where a controlled item is involved and a prohibition or licence requirement is identified, the question becomes whether a licence exception or a general or specific authorisation covers the transaction. The answer depends on the item's classification, the end user, the end use, and the destination.

General licences (standing authorisations that permit a defined category of transactions without a separate application) exist across OFAC's programmes and within the EAR's licence-exception structure. Their scope is programme-specific and can change; reliance on a general licence requires confirming its current terms, that the transaction falls squarely within them, and that no condition attached to the general licence has been breached. In our practice, we regularly advise businesses that have relied on a general licence without checking a critical condition – most commonly an end-use or end-user restriction buried in the instrument's text.

For the EAR, licence exceptions relevant to cloud and remote-access scenarios include those designed for encryption items and for certain technology released to foreign nationals of allied or partner countries. However, exception eligibility is strictly item-, end-use-, and destination-specific. A single exception does not cover an entire platform; it covers a defined transfer. Applying a broad exception to a recurring remote-access arrangement without per-transaction analysis is a common source of exposure.

Where no exception applies, a specific licence (a case-by-case authorisation to conduct an otherwise prohibited transaction) is required. OFAC licence timelines vary by programme and by the complexity of the request. BIS specific-licence timelines are similarly not fixed. Both should be treated as multi-month processes in the absence of specific guidance to the contrary, and neither process guarantees approval.

Decision branch summary: if the recipient is blocked or in a comprehensively sanctioned territory, stop – no licence route is available without OFAC authorisation. If the technology is EAR-controlled and no exception covers the access, a BIS or OFAC licence is required before access is granted. If neither condition applies, document that conclusion and build the record.

What are the cross-regime considerations that a US-only analysis misses?

An OFAC and EAR analysis resolves the US compliance question. It does not resolve the compliance question for a European or UK operator, a Singapore-based cloud provider, or a Japanese entity providing infrastructure. Each of those operators is subject to its own regime, and those regimes interact with the US position in ways that can tighten or complicate the analysis.

Under EU rules, a technology transfer to a person in a jurisdiction subject to EU restrictive measures – or to a designated person anywhere – requires analysis under the relevant Council Regulation. The EU dual-use regime (governed by Regulation (EU) 2021/821, the recast Dual-Use Regulation, as currently in force) covers exports of dual-use items, technology, and technical assistance, including intangible transfers. An EU-based cloud provider granting remote access to controlled computing infrastructure to a person in a restricted jurisdiction may require a national export authorisation from its member state's competent authority, entirely independently of any US licence.

The UK position under the Export Control Order and the ECJU is similar in structure. Controlled technology transfers, including intangible ones, require a licence where the item is on the UK control list and the destination or end user falls within a controlled category. The UK regime does not simply replicate the US CCL; classifications diverge, and an item that is EAR99 is not automatically outside UK control. UK financial-sanctions obligations under OFSI sit alongside the export-control layer: a payment made to a cloud-service provider that is itself subject to a UK designation raises an independent OFSI problem.

Japan implements controls under the Foreign Exchange and Foreign Trade Act (FEFTA), which covers technology transfers as well as physical exports. Singapore and the UAE each maintain their own frameworks. In our cross-border practice, the most frequently overlooked overlap is between US FDP jurisdiction and the separate export-authorisation requirements of the jurisdiction where the cloud infrastructure is physically hosted. An EU operator running US-origin workloads on EU-hosted hardware may face simultaneous US and EU licensing obligations on a single remote-access transaction.

Where two regimes both apply, the stricter prohibition governs the conduct of a person subject to both. Compliance requires satisfying all applicable regimes, not simply the most familiar one.

What are the principal risk flags, and what makes the exposure worse?

Several patterns in cloud and remote-access arrangements increase sanctions and export-control risk significantly. Identifying them early is the difference between a manageable compliance adjustment and a serious enforcement matter.

The first flag is geographic instability. An access arrangement that begins with a user in a permitted location can migrate: employees relocate, VPNs obscure true locations, and accounts are shared. A compliance programme that screens the user at onboarding but not on an ongoing basis is operating with a structural gap. Periodic re-screening and monitoring of login geography are not optional refinements; they are core controls.

The second flag is the aggregation of small access rights. A single user granted narrow access to a controlled workload may be within an exception. Multiple users, or a pattern of access that amounts to a sustained transfer of controlled capability, may not be. The EAR's controls on advanced computing capacity look at what is effectively transferred in aggregate, not only at individual sessions.

The third flag is the myth that commercial availability equals no control. This is addressed directly below, but the practical version of the risk is that a compliance team that skips classification because a product is sold commercially will not catch the cases where the commercial version incorporates controlled US-origin components subject to FDP rules, or where the platform was built using controlled US tooling.

The fourth flag concerns changes to the infrastructure. A cloud platform that migrates its compute nodes from a non-controlled jurisdiction to a new location, or that incorporates newly procured hardware subject to advanced-computing controls, changes the analysis for every existing access arrangement. Compliance teams that treated a platform as cleared at one point in time without a review trigger for infrastructure changes will miss this.

Records matter. Sanctions records must be kept for five years. A business that cannot reconstruct its classification analysis, its screening records, and its exception-eligibility assessment for a given access arrangement is in a weak position in any enforcement enquiry. Blocked-property and rejected-transaction reports are due to OFAC within 10 business days of the blocking or rejection. Missing that deadline, or failing to identify the event that starts it, compounds the original violation.

Does commercial availability mean an item is not controlled?

No. This is the objection we encounter most often from engineering and product teams, and it is one of the most consequential misunderstandings in this area of practice. The fact that an item is sold commercially, listed on a public vendor portal, or available without restriction to domestic customers does not determine whether it is controlled for export to a foreign person or for a remote-access transfer.

Classification under the CCL turns on the technical parameters of the item – processing speed, memory bandwidth, encryption strength, or other measurable characteristics – not on its commercial profile. An item with EAR99 designation is not subject to CCL licence requirements for most destinations, but it remains subject to OFAC's list-based and comprehensive prohibitions. An item with an ECCN that carries national-security controls is controlled regardless of how widely it is sold domestically.

The commercial-availability myth is particularly dangerous in the context of advanced computing. High-performance chips and the software stacks that run on them are commercially available from major vendors and yet are among the most closely controlled items in the current export-control environment. In our experience, the most common source of a compliance gap in cloud and remote-access arrangements is a team that assumed EAR99 status for hardware they had not independently classified, or that relied on a vendor's marketing classification rather than conducting its own ECCN analysis.

Independent classification – reviewing the technical specifications against the CCL and confirming whether any ECCN applies, what the stated controls are, and whether any licence exception is available – is not something that can be delegated to a vendor's compliance sheet. A business that processes or stores controlled workloads, or that provides access to controlled capacity, bears its own classification and control obligation.

How to handle cloud and remote-access technology controls under OFAC: the step-by-step decision sequence

The following decision sequence draws together the analysis in this guide. It represents the minimum steps a compliance team should take before granting, renewing, or continuing remote access to computing capacity that may be subject to US sanctions or export-control obligations.

Step 1 – Screen the recipient. Run the prospective user, its parent entities, and its beneficial owners against the SDN List and against the relevant comprehensive-programme restrictions. Apply the 50 percent rule: screen the ownership chain, not only the named entity. Retain the screening records.

Step 2 – Determine the geographic endpoint. Establish where the user will physically access the system from, and confirm this is not a comprehensively sanctioned territory or a jurisdiction subject to targeted restrictions relevant to the technology in question. Do not treat a VPN exit node as conclusive evidence of location.

Step 3 – Classify the technology. Determine the ECCN of the hardware and software being accessed. Do not assume EAR99. Review the technical specifications against the CCL, and consider whether FDP rules bring any foreign-manufactured component within EAR jurisdiction.

Step 4 – Assess licence exceptions and authorisations. If the technology is controlled, determine whether a general licence or a licence exception covers this specific transfer to this specific recipient for this specific purpose. Confirm the current terms of any general licence. Document the exception-eligibility analysis.

Step 5 – Apply for a specific licence where required. If no exception covers the transfer, apply for a specific licence before granting access. Do not grant access pending a licence application unless a specific interim authorisation permits it.

Step 6 – Assess cross-regime obligations. Where EU, UK, or other regime obligations apply to the operator or to the infrastructure, complete the parallel analysis under those regimes. Satisfy all applicable regimes before proceeding.

Step 7 – Implement ongoing controls. Build re-screening, login-geography monitoring, and infrastructure-change review triggers into the access arrangement. Set record-keeping obligations at the five-year minimum. Establish a reporting path for blocked-property or rejected-transaction events, including the applicable reporting window.

This sequence is a cloud and remote-access technology controls compliance checklist in practice. If any step produces an uncertain answer, that uncertainty is itself a risk flag that warrants specialist review.

Related practices

• Advanced computing controls under BIS and the EAR – classification, licence exceptions, and end-use controls for high-performance hardware
• Cloud and remote-access controls: UAE guide – how the UAE's framework interacts with US and EU obligations for technology transfers
• Country group changes under BIS and the EAR – understanding how reclassification affects licence requirements and exception eligibility

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