In 2020, a procurement team evaluating a cloud platform could check the encryption box and move on. "Encrypted at rest, encrypted in transit, TLS 1.2 or higher, AES-256." A vendor with that posture cleared most audit questions and most compliance questionnaires. The conversation typically ended there.

The conversation does not end there anymore. Across major regulatory regimes, the question after "is the data encrypted" has become "who holds the key, and who can compel them to use it". That second question reframes the problem entirely. It moves the burden of proof from the encryption algorithm to the operational and legal control of key material. And it makes a feature that used to be reserved for Fortune-500 procurement, Bring Your Own Key, the architectural default for any platform serving regulated industries.

This article walks through the regulatory shift that has put customer-controlled keys at the centre of trust models, why "BYOK" as commonly implemented is not always enough, and what architecture matches what regulators now expect.

What "encryption" used to mean to a procurement team, and what it means now

The pre-2020 conversation was about cryptographic strength. AES-128 was acceptable, AES-256 was preferred, RC4 was forbidden, TLS 1.0 was on its way out. The implicit assumption was that the vendor controlled both the data and the keys, and that the customer trusted the vendor to keep both safe. The audit answer was a certificate.

That assumption has eroded for two reasons.

First, the legal reach of cloud-provider jurisdictions has become a real risk surface, not a theoretical one. After Schrems II in 2020, the European Court of Justice held that data transferred to the United States was not adequately protected because US surveillance law allowed government access in ways incompatible with the General Data Protection Regulation. The European Data Protection Board's follow-up guidance was unusually direct: encryption alone is insufficient when the cloud provider holds the keys, because the provider can be compelled to decrypt. Customer-controlled keys retained inside the EEA were identified as the primary technical supplementary measure capable of addressing the exposure.

Second, the volume of regulator-driven control statements has converged on the same answer from different directions. The encryption algorithm is the easy part. Key custody is the hard part. And the hard part is the part being audited.

The frameworks pushing in this direction

The pattern is consistent. Five years of accumulated regulator language across very different jurisdictions all push the trust boundary in the same direction.

GDPR Article 32 (European Union). Article 32 lists pseudonymisation and encryption as examples of appropriate technical measures, framed as proportionate to the risk and informed by the state of the art. In 2020 the state of the art accepted provider-managed keys. After Schrems II the European Data Protection Board's supplementary-measures guidance explicitly elevated customer-controlled key material to the level of structural mitigation. The shift was not a Schrems II quirk; it became the working assumption for EU data exporters in any cross-border context, and the Digital Privacy Framework challenge currently before the CJEU keeps it relevant.

HIPAA Security Rule (United States healthcare). The 2025 proposed updates to the Security Rule, with a compliance milestone of 31 December 2025, mandate encryption for all electronic protected health information without the previous "addressable" carve-out. AES-256 becomes the baseline for data at rest, TLS 1.3 the baseline for data in transit, and encryption systems are expected to meet FIPS 140-2 Level 2 with Level 3 recommended for high-risk environments. Hardware security modules are named explicitly. Cloud-stored ePHI must use secure key management; AWS KMS and Azure Key Vault are cited as FIPS-validated options that support envelope encryption. Key rotation every 90 days is required for high-risk systems or immediately after a breach.

NIS2 directive (European Union). Article 21 of the directive requires policies and procedures for the use of cryptography and, where appropriate, encryption, as a mandatory security measure for essential and important entities. The 2026 amendments are explicit on a point that often gets overlooked: NIS2 does not prescribe which algorithms must be used; it requires that organisations prove they can change them. Crypto-agility is now a regulator expectation, not an engineering nicety. The 2026 amendments also introduce post-quantum cryptography migration policies with completion targeted between 2030 and 2035, which only matters if your platform can rotate algorithms and key types without rebuilding from scratch.

FINMA (Switzerland). The Swiss financial supervisor's Circular 2023/1 introduced the concept of "critical data", information whose confidentiality, integrity, or availability is essential for an institution's operations or for regulatory purposes. Such data must be identified, classified, and protected through appropriate technical and organisational measures. Cryptographic protection sits inside that mandate. Combined with the cross-border outsourcing rules in Circular 2018/3, which require that information needed for Swiss restructuring or resolution be accessible in Switzerland at all times, the practical answer is encryption with keys that the Swiss-regulated institution can exercise without depending on a foreign vendor.

ADHICS V2 (United Arab Emirates healthcare). The Abu Dhabi healthcare standard names encryption governance as a distinct domain. Strong encryption such as AES-256 is required for protected health information at rest and in transit, with hardware-security-module-backed key management and strict key governance expected. End-to-end encryption is required for all patient-data transmissions. Identity and access controls around key material are explicit. The combination amounts to a regulator-level expectation that the data controller, not the vendor, has meaningful operational control over key material in production.

SAMA Cloud Computing Regulatory Framework (Saudi Arabia). Saudi banks are required to keep core customer data, transaction records, and business continuity backups on infrastructure within the Kingdom. SAMA expects cryptographic protection of high-sensitivity tiers and inspection rights into the vendor's environment. Public-cloud use is permitted only where the provider operates certified Saudi regions and signs contracts that prevent unilateral data movement. Key control, alongside region control, is the practical mechanism that makes the localisation guarantee real.

Six frameworks, four jurisdictions. The vocabulary differs. The direction does not.

BYOK is not enough. The spectrum from provider-managed to customer-held

The shorthand "BYOK" is hiding important architectural distinctions that determine whether a regulator considers the trust boundary actually moved.

At one end of the spectrum is provider-managed encryption. The vendor generates the master key, stores it in their key management service, rotates it on their schedule, and uses it to wrap your data encryption keys. From a strict legal-control perspective, the vendor can decrypt your data at any time. Most "encrypted at rest" cloud platform implementations are exactly this. After Schrems II, this is the model the EDPB pushed customers away from for sensitive workloads.

In the middle is Bring Your Own Key, where the customer generates the master key (often in a hardware-security module) and imports it into the provider's key management service. The customer can theoretically revoke the key, but in practice the provider still has technical access to it while it is in use. The CLOUD Act and similar statutes mean the provider can be compelled to decrypt without the customer's consent. The Cloud Security Alliance and several follow-up legal analyses have argued that BYOK in this form does not fully satisfy the Schrems II supplementary-measures bar, because the keys are not solely under customer control.

At the far end is Hold Your Own Key, where the master key never leaves customer-controlled infrastructure. The provider can only use the key by calling out to the customer's key service, which the customer can refuse. This model gives the strongest sovereignty answer and the cleanest answer to "who can compel decryption". It is also the model that customer-controlled provider integrations (AWS KMS in a customer account with strict policy, Azure Key Vault under a customer-controlled subscription, HashiCorp Vault Transit on customer infrastructure, PKCS#11 hardware security modules under direct customer operation) all aim toward.

For most regulated workloads in 2026, the regulator's mental model assumes the customer can demonstrate that the vendor cannot unilaterally decrypt. Anything short of that is open to a finding.

What architecture matches the regulator's expectation

A platform that takes the trust-boundary shift seriously usually has the same handful of properties.

Customer-controlled key provider. The customer's organisation keyring is wrapped under a provider the customer manages. AWS KMS in the customer's AWS account, Azure Key Vault under the customer's tenant, HashiCorp Vault Transit on customer infrastructure, or a PKCS#11 hardware security module the customer operates. The platform integrates with these providers; the platform does not own them.

Per-organisation key isolation. One organisation's keys cannot decrypt another organisation's data. Cryptographic separation is enforced at the keyring boundary, not by query middleware. This becomes essential the moment a single platform serves customers across multiple jurisdictions: each customer's residency and key-custody story is independent.

Operation ledger. Every key use, every wrap, every unwrap, every rotation, every retirement is recorded with timestamp, actor, purpose, and outcome. This is the artefact regulators are increasingly asking for, and the artefact that converts the abstract "we use customer-controlled keys" claim into something an auditor can read.

Fail-closed behaviour. When the customer's key provider is unavailable, the platform fails closed for the active customer-wrapped data. It does not fall back to a provider-owned key, because doing so would silently re-introduce the vendor-trust dependency the customer paid to remove.

Configurable rotation and retirement. The customer drives key rotation on their schedule, and key version retirement is an explicit governed operation, not a vendor-driven event.

Crypto-agility. Per the NIS2 expectation, the algorithm in use must be changeable without rebuilding the platform. Post-quantum migration is the looming case that will make or break this property for the next decade.

These properties are not configuration toggles. They are architectural commitments. A platform built on provider-managed keys cannot evolve into a customer-controlled-key platform by adding a "BYOK" SKU; the change touches the wrap envelope on every encrypted column and every encrypted blob the platform stores.

The questions a serious procurement team should ask

The short version of the procurement conversation, given everything above:

  1. Who issues the master key, and can the vendor use it without your authorisation? If the answer is "we manage it for you", the trust boundary has not moved.
  2. Where does the key material reside, and which jurisdiction can compel access to it? Schrems II is the lens that made this question routine; CLOUD Act is the statute that makes it practical.
  3. Can you revoke the vendor's ability to decrypt your data today, without contacting them? If revocation requires a support ticket, the customer does not actually hold the key.
  4. What happens to active sessions when you rotate or retire a key? Failure to roll cleanly is how key changes get postponed for years and how the actual security posture stays stuck at the original commission date.
  5. Where is the audit trail of every key use, and is it tamper-evident? "We log it" is a 2020 answer. "We hash-chain it" is a 2026 answer.

A platform that answers each of these with an artefact rather than a paragraph is on the right side of the shift. A platform that asks for time to "investigate the specifics" is not.

The architectural answer

The five-year arc from BYOK-as-enterprise-upsell to BYOK-as-baseline-expectation tracks a deeper shift in how regulators conceive of cloud trust. The trust used to live in the contract: the vendor would promise, the auditor would verify. The trust now has to live in the architecture: the customer's control over the key material has to be exercisable, observable, and inspectable without anyone's help.

This is the design principle behind Novantra's encryption architecture. Customer-controlled providers across AWS KMS, Azure Key Vault, HashiCorp Vault Transit, PKCS#11 hardware security modules, and external key management services, all supported under Novantra's operation ledger that records every key use. Per-organisation key isolation that makes cryptographic separation a storage-layer fact rather than a code-path assumption. Fail-closed behaviour for active customer-wrapped data when the customer's provider is unavailable. Configurable rotation, retirement, and rewrap as governed customer operations, not vendor-driven sweeps. On Novantra's Sovereign deployment, the entire key-handling path runs inside the customer's own infrastructure.

None of these is a feature. Each is a piece of architecture that earns the customer's trust the way regulators now insist it be earned: by removing the need to trust the vendor in the first place.