This volume does not claim that identity and encryption-key management at a cloud provider is inherently malicious. It was modeled by an infrastructure architect, audited contradictorily by two AI systems, from publicly verifiable facts — provider technical documentation, published regulatory frameworks, open standard specifications. It prosecutes no one's intent. It documents a structural mechanism by which digital identity and the encryption key remain the last lock on an architecture, even when the orchestrator is open and the data portable, and proposes a workaround architecture explicitly framed as a proposal, not a deployed solution.

Encrypted data can, in theory, be copied bit for bit to another infrastructure. An identity cannot be copied the same way: it is not a static value, but the result of a continuous attestation process — verifying the origin of the request, the integrity of the call chain, the temporal validity of the token. Copying the representation of an identity without copying the attestation process that validates it produces nothing usable.

All three hyperscalers converge on the same architecture: the encryption key generated by their native managed service never leaves their HSMs, whatever the precise FIPS certification (Level 2 for Azure Key Vault Premium, Level 3 for AWS CloudHSM and Google Cloud HSM). The mechanism documented in Chapter I is therefore not a quirk of a single provider, but a shared architectural convention across the three main market players.

An organization that wants to change cloud providers without losing access to its already-encrypted data must either re-encrypt the entire relevant data volume with a new key before the switch — an operation whose cost grows linearly with the volume of data already accumulated — or accept remaining dependent on the originating provider's key service to decrypt what was already encrypted there, even after the compute infrastructure itself has switched.

Identity and the key are locked in both by an unintentional cumulative effect (Arthur) and by a structural asymmetry of ownership over the physical infrastructure that authenticates them (Grossman & Hart). The second anchor explains why this lock-in resists even an open orchestrator governance model (Vol. VII): software governance does not transfer ownership of the HSM.

Nothing in SecNumCloud's documented requirements obliges a qualified provider to guarantee the operational exportability of an encryption key generated under its control toward another provider's infrastructure. The referential protects the key's integrity and confidentiality while it remains with the qualified provider — it does not address its portability at the moment of exit.

Article 2, point 38, of the Regulation defines "exportable data" by explicitly excluding data whose export would expose the provider to a cybersecurity vulnerability, as well as assets protected by intellectual property rights or trade secrets. The notion of "digital asset", moreover, only covers elements for which the customer has a right of use independent of the contractual relationship with the provider being left. An encryption key generated and held by the provider's managed key service clearly meets neither criterion: it was never a right held independently of that contract, and its functional export could, by construction, fall under service security. Nothing in the text, however, explicitly settles this case — it is precisely this absence of unambiguous qualification, rather than a named exclusion, that constitutes the blind spot documented here.

A self-hosted application identity provider can authenticate human users and high-level services. It cannot, however, substitute for the hardware attestation that certifies a given workload is actually running on the hardware it claims to use — this attestation requires access to the provider's root of trust (security chip, hypervisor microcode), which no client software can reproduce from the outside.

An organization using SPIFFE/SPIRE can carry the same cryptographically verifiable workload identity across several cloud environments simultaneously — a necessary condition for a provider switch not to immediately break the application authorization chain.

Fully escaping this dependency requires giving up the most performant managed abstractions — Serverless, native PaaS — to drop down to a rawer compute level, where the organization itself controls hardware attestation (for example via its own security chips on infrastructure it owns). This is a functional freeze symmetric to those already accepted in Volumes VII and VIII: an explicit trade-off between operational comfort and sovereignty, not a costless solution.

No claim in this volume is presented as sourced from memory. This appendix lets any reader verify, step by step, what Amine asked for, what Claude independently verified before writing, and what Gemini validated, rejected, or had corrected — rather than integrating a suggestion under reserve.

Gemini rejected the proposal to reformulate the Keycloak/Vault replacement already covered in Volume IV, judged insufficient against the technical objection of workload identity. Claude redirected the empirical target toward SPIFFE/SPIRE and the KMIP protocol, verified independently before drafting Chapter III.

Claude confirmed both theoretical references through independent research (exact title, journal, volume, pages). He confirmed the empirical materiality on AWS KMS, Azure Key Vault (nCipher/Thales, FIPS 140-2 Level 2) and Google Cloud KMS (FIPS 140-2 Level 3) directly from each of the three providers' official documentation, as part of the global audit Gemini requested on the first draft. Claude flagged, rather than silently corrected, an error in the FIPS level Gemini initially advanced for Azure (Level 3 proposed, Level 2 confirmed by Microsoft's documentation).

Claude confirmed, from several concordant sources, the content of SecNumCloud's key-management requirements (generation, storage, distribution, revocation), none of which mention any obligation to port a functional key. Gemini had proposed a textual quotation of Article 30; Claude judged it too approximate to reproduce as-is after verification, and substituted a more precise anchor, grounded in the definition of "exportable data" (Art. 2, point 38 — cybersecurity-risk exclusion) and "digital asset" (right of use independent of the contract), corroborating Gemini's semantic-gap hypothesis without reproducing his inaccurate wording.

Claude confirmed, from several concordant technical sources, that node attestation in SPIRE relies on metadata APIs specific to each cloud provider (AWS EC2 instance identity document, GCP metadata tokens, Azure attestation). This confirmation let Claude validate Chapter III's central demonstration without asserting it from memory.

Gemini flagged a materiality asymmetry between AWS on one hand, Azure and Google Cloud on the other in Chapter I; Claude corrected it by injecting symmetric empirical materiality for all three providers. Gemini judged the legal uncertainty in Chapter II on the Data Act insufficiently textually anchored; Claude corrected it with an anchor on Article 2, points 37 and 38, after finding Gemini's proposed quotation was not verifiable as-is.

Gemini justified his initial audit report by stating he had meant the Azure Dedicated HSM service (Level 3) rather than Key Vault Premium. Claude verified this fact, true in isolation — Dedicated HSM does reach Level 3 — but noted that Gemini's original wording had grouped these two distinct Azure offerings under a single certification level, which amounted to a conflation. The correction Claude had already made in draft 2 (Level 2 for Key Vault Premium) remains accurate and needed no further adjustment after this counter-audit.