For all their legitimate law-enforcement and intelligence-gathering uses, cyber-surveillance tools are prone to abuse. Among other things, they can be used by states to target political opponents or to oppress certain ethnic or religious groups, or to steal an adversary’s data or attack critical infrastructure.
States have increasingly sought to use export controls to help prevent transfers of cyber-surveillance tools, including software, that could enable human rights violations or pose a threat to national security. Controls covering transfers of cybersurveillance hardware, software and technology have been introduced through the Wassenaar Arrangement, the European Union and national control lists and by way of a catch-all control in the EU dual-use regulation.
However, the growing use of the ‘software as a service’ (SaaS) model—in which a software application is hosted and used on a cloud server but not downloaded by the end-user—poses a particular set of challenges. States differ in how they apply export controls to cloud computing, including SaaS, and their interpretation of relevant legal provisions informs their application of licensing requirements and enforcement measures. This divergence opens potential loopholes and gaps that could be exploited for illicit procurement. It also creates a confusing landscape for companies that want to remain in compliance with the controls on cyber-surveillance tools and other software. This blog aims to highlight the export control compliance and enforcement challenges posed by SaaS and offers some thoughts on how states can close these gaps and achieve more effective oversight of the trade in cyber-surveillance tools.
The software as a service model and cyber-surveillance products
SaaS is a type of cloud computing in which the software is uploaded to a cloud server—which could be owned and operated by the software provider or by a separate cloud service provider—and made available for use without the end-user being able to download the software to a local device or storage medium. Familiar examples of SaaS include cloud-based collaborative work and e-mail solutions or design and engineering tools that are available directly via the internet without the need for download.
One type of cyber-surveillance tool that may be offered via the SaaS model is intrusion software. Controls on intrusion software were added to the dual-use control list of the Wassenaar Arrangement in 2013 and apply to software ‘specially designed or modified to avoid detection by “monitoring tools”, or to defeat “protective countermeasures”, of a computer or network-capable device’ in order to remotely extract or modify data and, in some cases, take control of the device.
Some companies also offer facial recognition software via the SaaS model. This may, under certain conditions, be subject to control in EU member states by way of the EU dual-use regulation catch-all control for unlisted cyber-surveillance items or potentially via national control lists. In July 2024 the United States also proposed adding facial recognition software to its national dual-use control list.
Challenges for export controls if cyber-surveillance tools are offered via the SaaS model
When software is made available through the SaaS model, there are three main actors: the software provider, the cloud service provider (who may also be the software provider) and the recipient end-user of the software (see figure below).
There are several actions in this model that may constitute an export. First, the software provider uploads the software to a cloud server, which may be owned by the software provider or by a separate cloud service provider. Second, once it is on the server, the party controlling access to the software (usually the software provider) grants access to the recipient, thus making the software available. Third, the cloud service provider may also (at least potentially) grant access to the software for maintenance purposes. And finally, the recipient end-user downloads the data gathered using the software.
To determine whether any of these actions constitutes an export and who would be considered the exporter, an export licensing authority may need to establish a number of things, including the locations of the server and the three actors; who had effective control over granting access to the software during each of these steps; and whether the software was made available to the cloud service provider, the end-user or both.
Typical steps in a transnational software-as-a-service model.
Key differences in states’ interpretations of controls on SaaS
States’ interpretations differ on some key points: whether making controlled software available through SaaS is considered an export; and if it is considered an export, who is the exporter and which parts of the transaction trigger licensing requirements. These differences are found even within the EU, where member states share a common regulation for dual-use export controls. Some states appear not to have settled on a consistent national interpretation thus far. As well as creating potential loopholes and gaps, this divergence makes compliance more difficult, particularly for companies that operate in several states with different interpretations.
For example, according to guidance published by the German export licensing authority, BAFA, the cloud server being located in a state outside the EU is sufficient to trigger a licensing requirement for uploading controlled software. Granting access and thereby making the controlled software available to a user in a third country may also constitute an instance of export or brokering and therefore trigger a separate licensing requirement.
Other states, such as the Netherlands and the United Kingdom focus instead on the location of the person or entity accessing the software—rather than the location of the server—when determining whether it is a controlled export.
The United States has indicated that granting or gaining access to controlled software via SaaS does not constitute an export per se if the software provider uses a certain industry-standard level of end-to-end encryption that prevents the cloud service provider or any of its agents (for example those performing maintenance on the server infrastructure) from accessing the software. However, this only applies if the software is unclassified and neither destined for a recipient that is a party of concern on the entity list—a tool used by the USA to list foreign persons and companies to which specific restrictions or licensing requirements apply—nor stored on a server in a country under an arms embargo.
What the different interpretations mean for oversight, controllability and enforcement
Different interpretations of key concepts, including ‘export’ and ‘exporter’, determine the level of oversight and the ability to impose controls and—where necessary—prohibit transfers using export control legislation. States need to consider whether their current legal interpretations and provisions regarding making software available through SaaS satisfies their need for oversight, including for sensitive transactions involving cyber-surveillance software. Whether their desired level of oversight is reached also depends on whether they have complementary legal measures other than export controls at their disposal that enable oversight or provide means of intervention.
However states frame their export controls, they need to think about how to enforce the controls, which requires having the appropriate capacities to respond when they suspect that unlicensed transfers have taken place or are imminent. There are also practical detection and enforcement challenges that make it difficult for states to claim jurisdiction and to collect the evidence required for establishing intent, who had effective control over granting access and whether controlled software was made available to a specific end-user.
Some states, including the USA, require a certain level of encryption to be applied for transfers of controlled software instead of a licensing requirement—an approach that is favoured by industry actors. However, relying only on the use of encryption could mean less attention is paid to the end-users and end-uses. It could also risk creating additional hurdles for enforcement investigations, particularly if states do not have the required digital forensics capabilities available to retrieve required information and retrace transfers and access.
Striking the right balance
The use of cloud computing and the provision of software via SaaS are both set to increase. As with all dual-use export controls, states need to find the right balance between ensuring regulatory control over potentially risky cyber-surveillance exports and limiting the burden on legitimate trade.
Industry representatives have called for harmonization across states in how export controls apply to software in order to facilitate compliance. This currently appears unlikely to happen, even in the EU, given states’ continued disagreement on key aspects of how controls apply. However, states should clarify their national interpretations concerning how export controls apply to cloud computing, including SaaS, and provide guidance and conduct outreach to companies to support their compliance efforts. At the EU level, the current process of drafting common guidelines on intangible transfers of technology provides a welcome opportunity to do this.
It is not yet well known how and to what extent companies are offering different types of cyber-surveillance tools via SaaS. National authorities should thus engage regularly with both domestic and multinational companies to stay on top of this development and ensure that their legal interpretations and enforcement capabilities are appropriate for controlling the trade in cyber-surveillance software. More exchange between states’ licensing authorities and enforcement agencies on the detection, investigation and prosecution of cases involving SaaS could also be useful to this end.
One way this could be achieved is through broader multilateral initiatives—such as the ‘Pall Mall Process’—that seek to regulate the trade in cyber-surveillance tools and could improve understanding of both the technical aspects of the trade in these tools and how export controls can complement other regulatory mechanisms.
Considering the threat that cyber-surveillance tools may pose to civic freedoms, open societies should strive to ensure, despite the technical and legal difficulties, that cyber-surveillance tools do not fall into the hands of actors who seek to misuse them.
With support from the Open Society Foundations, the SIPRI Dual-Use and Ams Trade Control Programmeis conducting a project focused on improving the implementation of export controls related to surveillance technologies.
ABOUT THE AUTHOR(S)
Kolja Brockmann is a Senior Researcher in the SIPRI Dual-Use and Arms Trade Control Programme.
Lauriane Héau is a Researcher in the Dual-Use and Arms Trade Control Programme at SIPRI.
For all their legitimate law-enforcement and intelligence-gathering uses, cyber-surveillance tools are prone to abuse. Among other things, they can be used by states to target political opponents or to oppress certain ethnic or religious groups, or to steal an adversary’s data or attack critical infrastructure.
States have increasingly sought to use export controls to help prevent transfers of cyber-surveillance tools, including software, that could enable human rights violations or pose a threat to national security. Controls covering transfers of cybersurveillance hardware, software and technology have been introduced through the Wassenaar Arrangement, the European Union and national control lists and by way of a catch-all control in the EU dual-use regulation.
However, the growing use of the ‘software as a service’ (SaaS) model—in which a software application is hosted and used on a cloud server but not downloaded by the end-user—poses a particular set of challenges. States differ in how they apply export controls to cloud computing, including SaaS, and their interpretation of relevant legal provisions informs their application of licensing requirements and enforcement measures. This divergence opens potential loopholes and gaps that could be exploited for illicit procurement. It also creates a confusing landscape for companies that want to remain in compliance with the controls on cyber-surveillance tools and other software. This blog aims to highlight the export control compliance and enforcement challenges posed by SaaS and offers some thoughts on how states can close these gaps and achieve more effective oversight of the trade in cyber-surveillance tools.
The software as a service model and cyber-surveillance products
SaaS is a type of cloud computing in which the software is uploaded to a cloud server—which could be owned and operated by the software provider or by a separate cloud service provider—and made available for use without the end-user being able to download the software to a local device or storage medium. Familiar examples of SaaS include cloud-based collaborative work and e-mail solutions or design and engineering tools that are available directly via the internet without the need for download.
One type of cyber-surveillance tool that may be offered via the SaaS model is intrusion software. Controls on intrusion software were added to the dual-use control list of the Wassenaar Arrangement in 2013 and apply to software ‘specially designed or modified to avoid detection by “monitoring tools”, or to defeat “protective countermeasures”, of a computer or network-capable device’ in order to remotely extract or modify data and, in some cases, take control of the device.
Some companies also offer facial recognition software via the SaaS model. This may, under certain conditions, be subject to control in EU member states by way of the EU dual-use regulation catch-all control for unlisted cyber-surveillance items or potentially via national control lists. In July 2024 the United States also proposed adding facial recognition software to its national dual-use control list.
Challenges for export controls if cyber-surveillance tools are offered via the SaaS model
When software is made available through the SaaS model, there are three main actors: the software provider, the cloud service provider (who may also be the software provider) and the recipient end-user of the software (see figure below).
There are several actions in this model that may constitute an export. First, the software provider uploads the software to a cloud server, which may be owned by the software provider or by a separate cloud service provider. Second, once it is on the server, the party controlling access to the software (usually the software provider) grants access to the recipient, thus making the software available. Third, the cloud service provider may also (at least potentially) grant access to the software for maintenance purposes. And finally, the recipient end-user downloads the data gathered using the software.
To determine whether any of these actions constitutes an export and who would be considered the exporter, an export licensing authority may need to establish a number of things, including the locations of the server and the three actors; who had effective control over granting access to the software during each of these steps; and whether the software was made available to the cloud service provider, the end-user or both.
Key differences in states’ interpretations of controls on SaaS
States’ interpretations differ on some key points: whether making controlled software available through SaaS is considered an export; and if it is considered an export, who is the exporter and which parts of the transaction trigger licensing requirements. These differences are found even within the EU, where member states share a common regulation for dual-use export controls. Some states appear not to have settled on a consistent national interpretation thus far. As well as creating potential loopholes and gaps, this divergence makes compliance more difficult, particularly for companies that operate in several states with different interpretations.
For example, according to guidance published by the German export licensing authority, BAFA, the cloud server being located in a state outside the EU is sufficient to trigger a licensing requirement for uploading controlled software. Granting access and thereby making the controlled software available to a user in a third country may also constitute an instance of export or brokering and therefore trigger a separate licensing requirement.
Other states, such as the Netherlands and the United Kingdom focus instead on the location of the person or entity accessing the software—rather than the location of the server—when determining whether it is a controlled export.
The United States has indicated that granting or gaining access to controlled software via SaaS does not constitute an export per se if the software provider uses a certain industry-standard level of end-to-end encryption that prevents the cloud service provider or any of its agents (for example those performing maintenance on the server infrastructure) from accessing the software. However, this only applies if the software is unclassified and neither destined for a recipient that is a party of concern on the entity list—a tool used by the USA to list foreign persons and companies to which specific restrictions or licensing requirements apply—nor stored on a server in a country under an arms embargo.
What the different interpretations mean for oversight, controllability and enforcement
Different interpretations of key concepts, including ‘export’ and ‘exporter’, determine the level of oversight and the ability to impose controls and—where necessary—prohibit transfers using export control legislation. States need to consider whether their current legal interpretations and provisions regarding making software available through SaaS satisfies their need for oversight, including for sensitive transactions involving cyber-surveillance software. Whether their desired level of oversight is reached also depends on whether they have complementary legal measures other than export controls at their disposal that enable oversight or provide means of intervention.
However states frame their export controls, they need to think about how to enforce the controls, which requires having the appropriate capacities to respond when they suspect that unlicensed transfers have taken place or are imminent. There are also practical detection and enforcement challenges that make it difficult for states to claim jurisdiction and to collect the evidence required for establishing intent, who had effective control over granting access and whether controlled software was made available to a specific end-user.
Some states, including the USA, require a certain level of encryption to be applied for transfers of controlled software instead of a licensing requirement—an approach that is favoured by industry actors. However, relying only on the use of encryption could mean less attention is paid to the end-users and end-uses. It could also risk creating additional hurdles for enforcement investigations, particularly if states do not have the required digital forensics capabilities available to retrieve required information and retrace transfers and access.
Striking the right balance
The use of cloud computing and the provision of software via SaaS are both set to increase. As with all dual-use export controls, states need to find the right balance between ensuring regulatory control over potentially risky cyber-surveillance exports and limiting the burden on legitimate trade.
Industry representatives have called for harmonization across states in how export controls apply to software in order to facilitate compliance. This currently appears unlikely to happen, even in the EU, given states’ continued disagreement on key aspects of how controls apply. However, states should clarify their national interpretations concerning how export controls apply to cloud computing, including SaaS, and provide guidance and conduct outreach to companies to support their compliance efforts. At the EU level, the current process of drafting common guidelines on intangible transfers of technology provides a welcome opportunity to do this.
It is not yet well known how and to what extent companies are offering different types of cyber-surveillance tools via SaaS. National authorities should thus engage regularly with both domestic and multinational companies to stay on top of this development and ensure that their legal interpretations and enforcement capabilities are appropriate for controlling the trade in cyber-surveillance software. More exchange between states’ licensing authorities and enforcement agencies on the detection, investigation and prosecution of cases involving SaaS could also be useful to this end.
One way this could be achieved is through broader multilateral initiatives—such as the ‘Pall Mall Process’—that seek to regulate the trade in cyber-surveillance tools and could improve understanding of both the technical aspects of the trade in these tools and how export controls can complement other regulatory mechanisms.
Considering the threat that cyber-surveillance tools may pose to civic freedoms, open societies should strive to ensure, despite the technical and legal difficulties, that cyber-surveillance tools do not fall into the hands of actors who seek to misuse them.
With support from the Open Society Foundations, the SIPRI Dual-Use and Ams Trade Control Programme is conducting a project focused on improving the implementation of export controls related to surveillance technologies.
ABOUT THE AUTHOR(S)