Achieving data sovereignty on AWS with independent cryptographic control by Eviden

Can an organization fully embrace AWS, generative AI, and advanced analytics while maintaining independent control over how its most sensitive data is protected — at rest, in transit, and in use? For regulated European organizations, this question is no longer purely theoretical. However, the highest levels of independent control are not required for every workload. Rather, it is each organization’s risk appetite that determines where external key management, application-level encryption, or confidential computing is warranted. For those workloads, native AWS capabilities like External Key Store (XKS) and AWS Nitro Enclaves, combined with partner solutions like Eviden’s key management platform, enable organizations to achieve independent data protection without sacrificing access to the full breadth of AWS services.

Why independent cryptographic control matters

Organizations across Europe are accelerating innovation on AWS, leveraging generative AI, advanced analytics, and cloud-native architectures. Whether building AI-powered diagnostics in healthcare, automating regulatory reporting in financial services, or modernizing citizen-facing systems in government, the capabilities are compelling. These organizations are moving critical workloads to AWS to gain speed, scale, and access to managed services that would take years to build internally.
When data is encrypted using AWS Key Management Service (AWS KMS), AWS infrastructure participates in key operations. For most workloads, this model is entirely appropriate, providing strong encryption with minimal operational overhead. However, certain organizations, guided by their risk appetite and data classification frameworks, determine that some [PB1.1]sensitive data requires encryption keys to remain entirely outside the cloud provider’s operational boundary.
Their reasoning typically centers on:

• Cross-border legal considerations: Holding key material outside the provider’s infrastructure ensures data remains inaccessible without the customer’s explicit participation.
• Internal governance requirements: Board-level mandates that cryptographic control must be demonstrably independent of any third party.
• Sector-specific risk postures: Data classification frameworks in healthcare, financial services, and public administration that require customer-controlled key infrastructure.

The regulatory environment reinforces this direction. The EU Sovereign Cloud Framework, DORA’s ICT risk management requirements for financial entities, and national certification schemes are progressively codifying expectations around cryptographic key independence. While no single EU-wide regulation mandates external key management for all cloud workloads today, the trajectory is clear. Organizations that adopt external key architectures now are not only addressing current risk but positioning themselves ahead of requirements that are rapidly moving from guidance to enforceable standards.
The challenge is not whether independent control is achievable on AWS, but how to implement it without introducing unnecessary complexity or performance constraints. AWS provides native mechanisms for external key integration, and Eviden’s Data Protection platform extends these with certified European cryptographic products. The key is matching the right pattern to the right workload, which is the focus of the next section.

Four patterns of cryptographic control

Sovereignty is not binary. Different workloads carry different risk profiles, and applying the highest level of control uniformly would introduce unnecessary complexity and cost. The right approach maps control levels to data sensitivity. Four architectural patterns form a progression:

• Pattern 1 – Bring Your Own Key (BYOK): Customer-generated keys imported into AWS KMS, giving the organization control over key provenance and rotation while AWS handles cryptographic operations. Appropriate when demonstrating independent key origin satisfies the workload’s risk requirements.
• Pattern 2 – External Key Store (XKS): Master keys remain entirely external to AWS, integrated via the XKS protocol. The customer retains full lifecycle control and can revoke access at any time; AWS never holds the key material. Eviden’s Proteccio HSM platform provides a validated XKS endpoint, maintaining all key material within European-operated infrastructure while connecting seamlessly to AWS KMS. Appropriate when the risk posture requires that key material never resides within the cloud provider’s boundary.
• Pattern 3 – Application-Level Encryption: Data is encrypted at the application layer before entering AWS storage or transit, giving the customer end-to-end control over the encryption process. The application can request keys to Eviden KMS and handle cryptographic operations or fully delegate them to Eviden KMS. Appropriate when plaintext data must not be exposed to cloud infrastructure at any point.
• Pattern 4 – Confidential Computing: Data, keys, and operations are protected during runtime using hardware-backed memory encryption provided by instances having CPU-based confidential computing feature (e.g. AMD SEV-SNP), giving the customer control over the processing environment itself. Eviden Confidential VM streamlines deployment, usage and monitoring of such solution. Appropriate for the highest-sensitivity workloads where protection during active computation is required.

Most organizations apply multiple patterns across their workload portfolio, matching control levels to data sensitivity. Eviden eases this approach for customers by making them all possible with the same pair of trusted technologies.

The question that follows is whether increasing levels of control necessarily introduce increasing operational burden.

Operational considerations

A common concern is that sovereignty comes at the cost of efficiency. If designed poorly, this concern is justified: external key calls can add latency, introduce failure points, and create operational complexity. However, when architected correctly, the operational impact is minimal and manageable. The two patterns that require the most deliberate design are XKS and Confidential Computing.

For External Key Stores (Pattern 2), application teams continue using standard AWS encryption APIs across Amazon S3, Amazon RDS, and Amazon EBS with no code changes, no special SDKs, and no reconfiguration of existing workloads. HSM-backed operations add single-digit millisecond latency per cryptographic call. Eviden delivers this capability as-a-Service through its KMS platform, backed by geo-redundant Proteccio HSM clusters across multiple European data centers. This removes the need for in-house HSM expertise and provides built-in high availability without customers having to architect resilience themselves. The result is enterprise-grade external key infrastructure with operational characteristics comparable to a native cloud service.

For Confidential Computing (Pattern 4), operational considerations center on enclave management, attestation workflows, and supported instance types. Eviden Confidential VM, available on the AWS Marketplace, streamlines them: deploy from the marketplace, install your application, take a snapshot for the attestation and you are ready!

BYOK and Application-Level Encryption (Patterns 1 and 3) introduce lighter operational requirements: key import and rotation governance for BYOK, and developer-managed encryption logic for application-level approaches. Neither fundamentally changes how teams interact with AWS services.

The following case study illustrates how these trade-offs play out in a production environment, particularly the balance between XKS coverage and operational efficiency.

Case study: European healthcare provider

A European hospital network processing rapidly growing volumes of medical imaging data (MRI, CT scans) on Amazon Simple Storage Service (Amazon S3) needed to scale its cloud analytics capabilities. However, the organization’s risk appetite, shaped by internal governance mandates and clinical data sensitivity, required encryption key custody to remain outside the cloud provider’s infrastructure. At the same time, clinical teams required sub-second access to imaging data for time-critical diagnostics. The business case for AWS was clear, but without resolving the key custody question, the national authority body would not approve expanding workloads.

The organization deployed Eviden’s managed KMS platform, with Proteccio HSM appliances hosted in a European data center, connected to AWS via the XKS protocol. The architecture provided full key lifecycle management, including automated rotation and audit logging, without requiring in-house cryptographic expertise. Encryption key operations added negligible latency to image retrieval, and the institution satisfied its national authority’s requirement for demonstrable key independence.

However, the initial implementation routed all encryption operations through XKS, including non-sensitive application data, generating unnecessary API calls to the external key infrastructure, hence unnecessary costs and throttling risks. To resolve this, Eviden leveraged its KMS platform’s Application-Level Encryption capability to apply encryption selectively — directing only sensitive clinical and patient data (classified under the organization’s data governance framework as requiring external key custody) through the Proteccio HSM infrastructure, while standard application data continued using conventional AWS KMS encryption.

This tiered approach brought API costs to a manageable level and eliminated throttling concerns. The hospital network could continue scaling its imaging and analytics workloads on AWS with full confidence that sensitive patient data remained under independent cryptographic control, while routine application data benefited from the simplicity of standard AWS KMS. The result demonstrated a key principle: sovereignty controls should be applied precisely where the risk profile demands them, not uniformly across all data.

Governance and continuous validation

Implementing the right architectural pattern is only part of the challenge. A complete sovereignty posture requires three complementary layers: technical controls (AWS-native governance through AWS Control Tower, AWS CloudTrail, and AWS Config) to embed policies into operational baselines; operational governance to ensure architecture decisions continue to reflect the organization’s evolving risk appetite; and continuous validation to detect drift and confirm that cryptographic and runtime protections remain effective as workloads scale and regulatory requirements tighten.

Eviden delivers this end-to-end capability, bridging the gap between technical implementation and a sustained sovereignty posture. Rather than treating sovereignty as a point-in-time deployment, Eviden’s approach encompasses ongoing key lifecycle management, periodic compliance validation, and proactive adaptation as regulatory frameworks such as DORA and the EU Sovereign Cloud certification move from guidance to enforceable standards. The result is sovereignty as a continuous operational discipline, not a one-off project.

Conclusion: Sovereignty without compromise

Key takeaways for decision makers:

• Each organization’s risk appetite, reinforced by evolving EU regulatory expectations, determines where independent data protection controls are warranted.
• Four architectural patterns exist, each matched to a defined risk profile. Most organizations apply multiple patterns across their portfolio.
• These patterns introduce trade-offs in performance and complexity, but these are manageable with the right design and expertise.
• Sovereignty is an ongoing operational discipline requiring continuous validation and governance integration.

Sovereignty does not require retreat from AWS. When designed correctly, it becomes an architectural property of the system that enables regulated organizations to innovate with confidence. With native AWS capabilities like External Key Store, combined with partner solutions like Eviden’s KMS and HSM platforms, organizations can achieve demonstrable independence over their data protection while accessing the full breadth of AWS services, from Amazon S3 and Amazon RDS to Amazon Bedrock and beyond. The path to sovereignty is clear; the architecture and expertise to deliver it are available today.