How to control remote access to computing power across regimes

A software company grants an overseas engineer remote access to a high-performance computing cluster. The engineer downloads simulation software, runs it on hardware the company controls, and returns results across a border. No physical item crossed a customs checkpoint. Yet several export-control regimes may have been triggered simultaneously. As of January 2026, regulators on both sides of the Atlantic are scrutinising exactly this pattern.

Cloud and remote-access technology controls cross-border guide: controlling remote access to computing power is a multi-regime obligation. Under the US Export Administration Regulations, releasing controlled technology to a foreign person – including through remote access from inside the United States – constitutes a deemed export (a transfer treated in law as an export to the person's home country). The EU recast Dual-Use Regulation and the UK Export Control Order carry analogous concepts. Where more than one regime applies, the stricter prohibition governs.

This guide takes the question step by step: how to classify what you are sharing, which regimes bite and when, the cross-border comparison that determines your licence position, and the risk flags that should trigger legal review before access is granted.

Step 1: Classify the technology before you grant access

Classification is the threshold question – and the answer determines whether you have an export-control problem at all. Under the EAR, every item subject to the regulations carries an ECCN (Export Control Classification Number under the US Commerce Control List), or sits in the residual category EAR99 (items subject to the EAR but not listed on the CCL). High-performance computing technology – processors, accelerators, simulation software, and the technical parameters associated with them – frequently falls within controlled ECCN categories. The same item may carry a separate classification under EU Regulation 2021/821 (the recast Dual-Use Regulation) and under the UK Military and Dual-Use Lists.

The classification exercise is not a one-time event. Parameters change; the CCL is updated; a chip that was EAR99 last year may not be EAR99 today, particularly in the advanced computing space where control thresholds have been revised in recent regulatory cycles. In our practice, the most common starting error is relying on a classification that was correct at product launch but has not been revalidated since.

For remote access specifically, the relevant question is not only what hardware the user will touch but what technology – source code, algorithms, technical data – they will be able to access or derive during the session. A user who can observe operational parameters of controlled equipment may be receiving controlled technology even if they never download a file. Map the access carefully before you classify it.

Step 2: Apply the deemed-export and deemed-re-export rules

The deemed-export concept is central to the remote-access analysis under the EAR. Releasing controlled technology or source code to a foreign person inside the United States is treated as an export to that person's country of nationality. The same logic extends to re-exports: releasing controlled technology to a foreign person outside the United States, in a third country, constitutes a deemed re-export to the person's home country.

What does this mean for a cloud or remote-access arrangement? If a UK-based employee remotely accesses controlled software running on a US server, the release of technology to that person is a deemed export from the US to the UK. If the employee holds dual nationality, both countries of nationality are in scope. The nationality analysis is not the employer's main line of defence – the question is whether the technology is controlled and whether a licence exception or authorisation covers the release.

The EU and UK frameworks have comparable – though not identical – concepts. Under EU dual-use rules, the provision of technical assistance connected to controlled items, including via electronic means, can engage the regulation. Under the UK Export Control Order, the transfer of controlled technology by electronic means is an export. Neither regime uses the precise "deemed export" label, but the practical effect is the same: remote delivery of controlled technology is regulated delivery. Where all three regimes apply to the same arrangement – because the operator is a US person, the technology is US-origin, and the recipient is in an EU or UK jurisdiction – each regime's analysis must be run separately, and the most restrictive position applies to the conduct of a party subject to all three.

Step 3: Identify whether a licence exception or authorisation covers the access

Having established that the access is a regulated transfer, the next step is to determine whether it is already authorised without a specific licence. Under the EAR, licence exceptions are item-, end-use-, and destination-specific. For technology transfers, exceptions such as Technology and Software – Unrestricted may be available for lower-controlled items to lower-risk destinations, but they carry conditions. Advanced computing technology – particularly items caught by recent CCL revisions – is frequently ineligible for the most permissive exceptions.

The destination matters enormously. A country's export-control country-group classification determines which exceptions are available and what licence requirements apply; reclassification changes the analysis prospectively and does not grandfather existing arrangements. An access arrangement that was permissible under a prior classification may require a licence review following a reclassification. The UAE, for example, was re-grouped in a 2026 final rule, which changes the exception and licensing analysis for arrangements involving UAE-based recipients – though as that rule is recent, verify the current position before relying on it.

Under EU Regulation 2021/821, general authorisations exist for intra-EU transfers and for exports to certain country groups, but they carry conditions including record-keeping, end-use assurances, and in some cases prior notification. The UK operates a parallel system of Open Individual Export Licences and Standard Individual Export Licences (OIELs and SIELs), with open general licences available for defined categories of goods and destinations. The conditions attached to open licences are frequently underread; a licence that covers hardware may not cover the software or technical data transferred remotely alongside it.

In our experience, the exception-mapping step is where transactions stall, because the answer is often "partially covered": the hardware is fine, the software needs a licence, and the technical data discussions during onboarding are not covered at all. Treat each element of the access arrangement separately.

Step 4: Run the cross-border comparison – which regime is strictest?

Where multiple regimes apply, the stricter prohibition governs the conduct of a person subject to both. This principle is easy to state and difficult to apply, because the regimes do not line up perfectly. An item controlled under the EAR may be EAR99 in the EU classification and vice versa. A destination that is licence-free under the UK rules may require a specific licence under the EAR because of Foreign Direct Product considerations.

The Foreign Direct Product rules (FDP rules) extend US jurisdiction extraterritorially. Certain foreign-produced items are subject to the EAR when they are the direct product of controlled US technology or software, or when they are produced by a plant that itself is the direct product of such technology. For cloud and remote-access arrangements, this means that a non-US operator providing access to a computing environment built on US-origin technology may be subject to EAR requirements even if the operator is not a US person and the servers are not in the United States. The threshold is item- and programme-specific; the analysis must be done at the technology level, not at the transaction level.

The EU Blocking Regulation adds a further dimension for EU operators. Where a third-country measure – most relevantly a US secondary-sanctions or export-control measure – is listed in the Blocking Regulation's Annex, an EU operator may be prohibited from complying with it without prior authorisation from the relevant Member State authority. This creates a direct tension: the operator may face US exposure if it does not comply, and EU exposure if it does. In cross-border cloud arrangements where both US and EU rules are live, this tension is not theoretical. It requires a structured legal analysis before the access arrangement is signed.

The practical output of this step is a jurisdiction matrix: for each regime in play, what is the classification, what is the licence position, what exceptions are available, and what is the record-keeping obligation? That matrix becomes the basis for the go/no-go decision and for structuring any application for specific authorisation.

Step 5: Build the access controls and compliance documentation

The analysis completed in steps one to four must translate into operational controls before access is granted – not afterwards. A compliance position on paper does not protect an operator whose access architecture is inconsistent with it.

For cloud and remote-access technology controls cross-border step by step, the minimum documentation set includes: a written technology-control plan or technology transfer plan covering the specific access arrangement; nationality verification and end-user screening for all personnel who will receive access; a licence or exception determination with supporting analysis; and a record of each access session sufficient to demonstrate compliance with any conditions. Under the EAR, sanctions records must be kept for five years; other regimes have comparable retention requirements, and in our practice we advise building the system to satisfy the most demanding obligation in the set.

Access architecture should reflect the licence position. If the licence exception available requires that access be limited to nationals of permitted destinations, the system must technically enforce that limitation – not rely on human compliance. Role-based access controls, geographic restrictions, and session logging are the engineering counterparts of the legal analysis. Where access is being given to a joint-venture partner, a customer running a proof of concept, or an academic collaborator, each of those relationships should be documented with an end-use statement covering the technology being accessed.

Screening is a necessary but not sufficient control. "We screened the name" is not a complete compliance programme. Screening must cover the individual, the employer, any intermediate entities, and the end use – and it must be repeated at material intervals, not only at onboarding. Designation lists change; a recipient who was unproblematic at onboarding may appear on a list a year later. The cloud and remote-access technology controls compliance checklist should include a periodic re-screening trigger.

Step 6: Recognise the risk flags and know when to involve counsel

Certain patterns recurrently signal that an access arrangement needs formal legal review before it proceeds. Involving sanctions and export-control counsel early is not a sign that the transaction is impermissible; in our experience, it is usually the fastest route to a workable structure.

The risk flags include:

• The computing power being accessed processes items with known military, intelligence, or advanced manufacturing end-uses, regardless of the stated purpose of the access.
• The recipient is a national of, or is located in, a jurisdiction subject to arms-embargo, catch-all, or heightened-scrutiny controls under any of the regimes in play.
• The technology stack includes US-origin components – hardware, software, or foundational IP – that may bring the FDP rules into scope for a non-US operator.
• The access arrangement involves a joint venture, a research collaboration, or a service-provider relationship where the ultimate end-users are not directly known to the operator.
• A change in regulatory classification has occurred since the arrangement was last reviewed, particularly in the advanced computing category where CCL thresholds have been revised.
• The arrangement spans both US and EU obligations in a way that engages the potential Blocking Regulation tension described in Step 4.
• The access is to a cloud environment operated by a third-party provider whose own licensing and compliance architecture has not been reviewed.

A common misconception is that commercially available technology cannot be export-controlled. This is incorrect. The EAR applies to items that have commercial applications; commercial availability is not a control-free designation. An item's ECCNs classification and destination determine the licence requirement, not its commercial character. If a product is sold freely on the open market in the United States, it may still require a licence for export to certain destinations or persons. How to handle cloud and remote-access technology controls under cross-border arrangements in practice means treating the commercial-off-the-shelf assumption as a risk, not a safe harbour.

Counsel adds most value at two points: at the structuring stage, before the access architecture is fixed; and when a classification question is genuinely novel or the jurisdiction matrix produces an apparent conflict. Attempting to resolve an FDP analysis or a Blocking Regulation tension without specialist input is a known source of enforcement exposure. We regularly advise operators who have entered into cloud agreements first and discovered the export-control dimension later. Early involvement is cheaper in every sense.

Related practices

• Advanced computing controls – BIS / EAR service – classification, licence applications, and end-use controls for advanced computing items
• Cloud and remote-access controls – OFAC guide – OFAC sanctions screening obligations in cloud and remote-access arrangements
• Cloud and remote-access controls – UAE guide – UAE-specific controls and reclassification analysis for cloud arrangements

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