How TEEs Are Rewriting the Rules of Data Privacy
Sweden’s data protection authority has published landmark guidance on Trusted Execution Environments – and why the verifier is the linchpin of GDPR-compliant data processing.
Sweden’s data protection authority, Integritetsskyddsmyndigheten (IMY), has released a detailed final report from its innovation sandbox programme. It concludes the work done alongside Volvo Group, Ericsson, and CanaryBit to tackle a question quietly reshaping cloud computing: can data be processed outside an organisation’s own infrastructure without sacrificing the control that GDPR demands? The answer is yes – but only if you get the architecture right. And getting it right depends above all on the verifier.
The Problem
Volvo’s trucks carry cameras and sensors generating continuous video streams, positioning data, and telemetry. Processing all of it onboard is impossible – the hardware is not powerful enough, while additional hardware consumes more energy and generates heat. The data has to go somewhere else. That’s the problem. The moment data leaves a controlled environment and travels to an external provider, the data controller loses direct physical control. In a conventional cloud arrangement, the provider can – at least in principle – access what it processes on your behalf. You sign contracts; you write data processing agreements; you hope. The legislators did not design GDPR to run on hope. Article 32 demands appropriate technical and organisational measures. For years, the industry has leaned heavily on the “organisational” side: contracts, audits, certifications. The IMY sandbox asked whether technology can do more of the heavy lifting and examined Trusted Execution Environments (TEEs) as an answer.
What is a TEE?
A TEE is a hardware-enforced enclave inside a processor where code runs and data is processed in complete isolation. The operating system canot see inside it. The infrastructure provider canot reach into it. Data enters encrypted and is decrypted only within the enclave. If anything deviates from the pre-approved state – unauthorised code detected, security configuration changed – the enclave shuts down instantly and destroys everything inside it. IMY describes this as a self-destructing safe. There are no slow leaks, no gradual exfiltration, no window for an attacker to map the system over time. In a conventional cloud, security rests on the provider’s promises. In a TEE, it is enforced by the hardware itself. IMY is explicit: TEEs qualify as a technical safeguard under Article 32 of GDPR. They shift the basis of trust from contractual commitments to cryptographic proof. A data controller using a properly implemented TEE does not merely have assurances that their processor will behave correctly – they have verifiable, cryptographic evidence of it.
Two Architecture Decisions That Changed Everything
The Volvo-Ericsson-CanaryBit implementation differs from standard commercial TEE deployments in two ways that proved decisive in IMY’s legal analysis. User-controlled attestation. In most commercial cloud TEE offerings, the same provider that operates the infrastructure also controls the attestation process – the mechanism that certifies the enclave is genuine and uncorrupted. This is a conflict of interest: you are asking the party that could theoretically access your data to certify the environment protecting it. In this project, Volvo retains control of the attestation function entirely, setting the requirements for what counts as a valid, trusted enclave. The mobile operator providing infrastructure has no ability to influence this. User-controlled key management. Volvo holds encryption keys, not the mobile operator. The deployment only releases keys into the enclave only after successful attestation, and are cryptographically bound to the enclave’s specific state – they cannot be used in a compromised environment. The mobile operator has no cryptographic pathway to the data, even in theory. Together, these features mean the mobile operator supplies compute power and connectivity – and nothing more.
The Verifier: Where GDPR Accountability Lives
Everything above depends on one component: the verifier (the “kontrollantfunktion” in the report). The verifier receives the cryptographic proof generated by the TEE, checks it against pre-approved security requirements, and decides whether data is permitted to enter the enclave. Approve – keys are released, processing begins. Reject – nothing proceeds. Frequent attestations matter too: the more regularly the verifier checks the enclave’s state, the faster any deviation is detected and shut down. IETF’s RFC 9334 establishes the standardised architecture for remote attestation. It formalises the roles and protocols that govern this process across hardware platforms. CanaryBit builds tools that implement this architecture at scale. Our tools enable organisations to deploy TEEs at scale and operate verifiers that assess TEE attestations reliably and in accordance with defined security policies. IMY’s legal analysis makes the verifier’s significance impossible to overstate. Whoever controls the attestation function holds decisive influence over the essential means of processing – including who can access data in the TEE. Under GDPR, “essential means” is central to determining who is a data controller. When Volvo controls the verifier, Volvo controls the essential means. The mobile operator, controlling only infrastructure, cannot be considered a data controller or joint controller. IMY goes further: with no keys, no attestation authority, and no technical ability to see the data, there is a strong argument the mobile operator does not even qualify as a data processor in the traditional sense. Instead, it is more akin to a utility provider than a GDPR actor. This is a significant finding for the industry. It means that under the right conditions, organisations can use external infrastructure without those providers acquiring GDPR data processing obligations, because they genuinely cannot process the data.
Caveats
IMY is careful not to oversell. TEEs do not eliminate all risk: side-channel attacks and hardware-level exploits have, in research settings, demonstrated the ability to circumvent some implementations. Trust ultimately traces back to the hardware manufacturer. Moreover, TEEs cannot compensate for poor application code, misconfiguration, or unclear accountability between parties. However, they are a powerful layer in a broader security architecture, not a substitute for engineering discipline.
The Takeaway
This report is, in several respects, groundbreaking. This is the first time a European regulator has provided detailed GDPR guidance on TEE deployments grounded in a real operational scenario. It establishes a clear framework: control the verifier and the keys, and you retain control over the essential means of processing. Lose control of them, and you hand that authority – and the legal accountability that comes with it – to your infrastructure provider. For organisations building on TEE infrastructure, the practical implication is simple: the verifier is not a component to be delegated. It is where GDPR accountability lives.
