Chapter 13 — Secrets, Identity, and Access in a Sovereign Multi-Cloud Estate

Summary

This chapter establishes identity, secrets and access management as the control fabric on which every other assurance in the sovereign operations architecture depends. It traces the shift from network-perimeter security to zero trust principles, showing how federated identity stacks, sovereign zone constraints on trust relationships, and privileged access management with just-in-time credentials replace the assumptions that multi-cloud estates have rendered obsolete. Architects will find practical guidance on HashiCorp Vault for federated secrets management with dynamic credential issuance, SPIFFE/SPIRE for vendor-neutral workload identity, certificate lifecycle automation with cert-manager and Vault PKI, and the encoding of identity policy as infrastructure as code enforced by Open Policy Agent. The chapter also addresses the specific identity requirements of non-human actors, including AI agents and automation pipelines, and the access governance processes needed to satisfy DORA, ISO/IEC 27001 and GDPR audit obligations. A dedicated section on securing the sovereign control plane provides the identity and access specifics behind the distributed trust model introduced in Chapter 4: mTLS with SPIFFE/SPIRE for machine-to-machine authentication, FIDO2/WebAuthn hardware keys for human administrative access, dynamic credential issuance with no standing privilege, and anomaly detection on the control plane’s own access patterns. A further section on post-quantum cryptography and cryptographic agility examines the quantum threat to long-lived sovereign data, the NIST post-quantum standards (ML-KEM, ML-DSA, SLH-DSA), the architectural discipline of making cryptographic algorithms swappable without system redesign, and the role of confidential computing (Intel SGX, AMD SEV-SNP, IBM Hyper Protect) and homomorphic encryption in protecting data in use within sovereign zones.

13.1 Why identity is the new perimeter

There was a time when the discipline of network security could be summarised in a single mental model: draw a hard boundary around the organisation’s infrastructure, defend that boundary vigorously, and trust everything inside it. Firewalls at the data centre edge, VPNs for remote workers, and strict controls over physical access to premises gave this perimeter its teeth. For decades, it was the primary answer to the question of how you kept the wrong people out of sensitive systems.

Multi-cloud operations have made that answer obsolete. In a sovereign, multi-cloud estate of the kind this book describes, there is no single perimeter to defend. Traffic moves between AWS, Azure, Google Cloud and on-premises environments. Developers access systems from anywhere. SaaS platforms sit in critical operational paths. Third-party APIs are woven into business-critical services. Containers are orchestrated across clusters in multiple jurisdictions. AI agents traverse multiple systems to gather context and execute workflows. Attempting to draw a network perimeter around this kind of estate is not merely difficult; it is conceptually incoherent.

The consequence is that access policies enforced by identity have become the primary control boundary. If you cannot trust that every actor — human or machine — presents a verified identity before being granted access to a system, and if that access is not scoped to precisely what is necessary for the task at hand, then no combination of firewalls, VPNs and network segmentation will give you adequate assurance. The US National Institute of Standards and Technology made exactly this argument in NIST SP 800-207, the Zero Trust Architecture special publication, which articulates that in a zero trust model “no implicit trust is granted to assets or user accounts based on their physical or network location” and that “all communication is secured regardless of network location” [1]. The US Cybersecurity and Infrastructure Security Agency reinforced this in the Zero Trust Maturity Model v2.0, which places identity as the first of five pillars and characterises mature identity controls as the foundation on which every other zero trust capability depends [2].

Regulators have reached similar conclusions from a different direction. The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554 [3], requires financial entities to maintain ICT risk management frameworks that include robust access controls, with documented policies for authentication, authorisation and privileged access. Article 9 of DORA specifically requires that firms implement need-to-know and least-privilege principles, maintain logs of access to ICT systems, and control privileged access through dedicated management procedures. The NIS2 Directive [4] extends comparable expectations to a much wider set of essential and important entities. GDPR Article 32 [5], meanwhile, requires appropriate technical measures to ensure a level of security appropriate to the risk, which data protection authorities have consistently interpreted as requiring strong access controls and audit trails for systems processing personal data.

The practical upshot is that identity and access management is no longer a supporting function somewhere beneath the “real” engineering. It is a first-class architectural concern that sits at the intersection of operational resilience, data sovereignty and regulatory obligation. The chapters that follow this one — dealing with IBM Concert’s topology model and the Governance and Audit Plane introduced in Chapter 4 — depend on identity being trustworthy: Concert’s view of which agents have accessed which systems, which operators approved which changes, and which workloads are running in which sovereign zones is only meaningful if the identities underpinning those relationships are reliable. Similarly, the zero-copy integration substrate described in Chapter 6 relies on access policies, not network location, to enforce who may query data at source. If identity is weak, the access governance the rest of the architecture depends upon collapses.

This chapter works through the layers of the identity and access problem in a sovereign multi-cloud estate, from federated identity at the top to secrets management at the bottom, with attention throughout to the requirements of agentic operations, sovereign zone constraints and regulatory audit obligations.

13.2 The sovereign identity stack

Every organisation operating in a multi-cloud environment inherits a layered identity problem. At the enterprise level, there are authoritative identity sources: Microsoft Active Directory, an LDAP directory, or an enterprise identity provider (IdP) such as Okta, Ping Identity or ForgeRock. These systems hold the canonical record of who works for the organisation, what groups they belong to, and what their employment status is. At the cloud level, each provider has its own identity and access management system: AWS IAM Identity Center, Azure Entra ID (formerly Azure Active Directory), and Google Cloud IAM. At the platform level, Kubernetes clusters have their own role-based access control (RBAC) systems. At the application level, individual services may have their own access models.

Federating across these layers is technically achievable but architecturally demanding. The dominant protocols are OpenID Connect (OIDC), defined in RFC 6749 for the underlying OAuth 2.0 authorisation framework [6] and RFC 6750 for bearer token usage [7], and SAML 2.0, which remains widely deployed in enterprise environments, particularly for browser-based single sign-on. OIDC has become the preferred mechanism for machine-to-machine and API-centric scenarios, because it produces compact, self-contained JSON Web Tokens (JWTs) that carry identity claims in a form that downstream services can validate without querying the issuing authority for each request. SAML remains useful for legacy enterprise applications and for federation scenarios where session management and attribute-rich assertions are required.

The identity federation landscape is also evolving at the regulatory level. The revised eIDAS Regulation (eIDAS 2.0), adopted in 2024, establishes the European Digital Identity Wallet as a means for citizens and organisations to authenticate and share verifiable credentials across borders within the EU [22]. For sovereign estates that interact with citizen-facing or cross-border services, the EU Digital Identity Wallet will become an additional identity source that federation architectures must accommodate alongside enterprise IdPs and cloud IAM systems. Separately, PCI DSS v4.0 has tightened multi-factor authentication (MFA) requirements, mandating MFA for all access to the cardholder data environment — not merely administrative access — and requiring that MFA implementations resist replay and real-time phishing attacks [23]. Organisations processing payment card data within sovereign zones must ensure that their identity stack satisfies these strengthened MFA requirements at every authentication boundary.

In a sovereign multi-cloud architecture, the federation design must satisfy constraints that go beyond simple convenience. Identity claims must not traverse zone boundaries without explicit policy approval. If an operator’s identity assertion is issued by a corporate IdP in jurisdiction A, and that assertion grants access to systems in sovereign zone B, then the crossing of that zone boundary must be authorised by a policy that has been deliberately constructed, not merely permitted by a default trust relationship inherited from a cloud provider’s global configuration. This is a harder requirement than it sounds. Cloud providers, by default, tend to create broad trust relationships: a user authenticated to Azure Entra ID in one region may, by default, have the ability to access resources in any Azure region that the organisation operates in. Sovereign zone isolation requires overriding those defaults systematically.

The architecture that satisfies this requirement typically involves several components working together. A corporate OIDC/SAML IdP acts as the authoritative identity source for human users. Cloud provider federation trusts this IdP but is configured with conditions and attribute mappings that restrict what claims are accepted, from whom, and for which purposes. Cloud-level role assignments then map accepted identity claims to specific cloud IAM roles whose scope is zone-aware: an operator may be permitted to assume a read-only role in any zone, but a write role only in zones where their employment contract and clearance level are confirmed. Kubernetes clusters in each sovereign zone are configured to trust only a specific set of OIDC issuers — the IdPs that are authoritative for that zone — preventing an operator in one zone from using their identity to authenticate to clusters in another.

The sovereign identity stack

Achieving this level of control at scale requires infrastructure as code, a theme developed in Chapter 11. IAM role definitions, trust policies and federation configurations must be managed in Git and deployed through pipelines, not configured manually through cloud consoles. Manual configuration at this layer is how subtle misconfigurations accumulate: a trust relationship extended “temporarily” for a project that becomes permanent; a wildcard in a trust policy that opens an unintended path; a federation attribute mapping that maps a broader set of claims than intended. When federation configurations are expressed as Terraform or CloudFormation, those decisions are visible in code review and are subject to the same policy-as-code checks applied to all infrastructure changes.

13.3 Privileged access in a multi-cloud estate

Privileged access — access to systems with the ability to make material changes, read sensitive data, or administer identity and key management systems — is where the risk is highest and the controls most frequently inadequate. In a multi-cloud estate of even modest size, the number of roles, service accounts, and credentials with elevated permissions grows rapidly. Platform engineers need access to Kubernetes cluster administration. Security teams need access to audit logs. Database administrators need access to production data. Automation pipelines need service account credentials with write access to infrastructure. Over time, these privileges accumulate: accounts that were provisioned for a specific task and never deprovisioned; roles that grant more than they need because restricting them would require effort that no one has prioritised; service accounts whose passwords have not rotated in two years because the application using them would break if they did.

DORA Article 9 [3] is explicit that privileged access must be subject to dedicated management procedures, separation of duties, and access reviews. ISO/IEC 27001:2022 [8] requires access rights to be reviewed at regular intervals and adjusted or revoked when changes occur. Neither framework prescribes specific tools, but both create an expectation that privileged access is not an afterthought — that it is documented, controlled, monitored and periodically verified.

The primary technical controls for privileged access at scale are privileged access management (PAM) platforms. CyberArk, which has published extensively on the scope of the privileged access problem in cloud environments [9], provides a platform that vaults privileged credentials, manages session recording for audit purposes, and enforces just-in-time (JIT) access workflows: instead of granting a standing privileged role that is always active, operators request elevation for a specific purpose, for a bounded duration, and with a justification that is recorded. The credential is issued for that session only and is then invalidated. HashiCorp Vault, discussed further in section 13.4 in the context of secrets management, also provides dynamic credential issuance for privileged access: rather than storing a long-lived administrative password, Vault issues a short-lived credential on demand, records the issuance event, and revokes it automatically when the lease expires. IBM Secrets Manager provides analogous capabilities within the IBM cloud ecosystem.

The principle of least privilege must be applied at the role definition level, not merely at the user assignment level. In practice, this means decomposing coarse-grained administrative roles into fine-grained function roles: a role that can only read application logs is preferable to a role that can read all logs in all accounts; a role that can only scale specific Kubernetes deployments is preferable to a role with cluster-admin privileges. Cloud providers offer the mechanisms — AWS IAM condition keys, Azure role conditions, Google Cloud IAM conditions — but applying them consistently across a multi-cloud estate requires deliberate effort and ongoing review.

Session recording is a frequently underutilised control. When a human operator or an automated process takes elevated access to a sensitive system, recording the session — which commands were run, what data was viewed, what changes were made — creates an audit trail that is valuable both for post-incident investigation and for demonstrating regulatory compliance. PAM platforms typically include session recording as a core capability, and the recordings should be stored in tamper-evident storage within the appropriate sovereign zone: a session involving regulated data in zone A should be recorded and retained in zone A, not in a shared global audit store.

13.4 Secrets management across sovereign zones

The word “secret” in this context covers a spectrum of sensitive material: API keys that authenticate to third-party services, database credentials used by application code, TLS certificates that authenticate network endpoints, signing keys that ensure message integrity, and encryption keys that protect data at rest and in transit. Each has different lifecycle characteristics, different rotation requirements, and different consequences if compromised. An API key for a non-critical analytics service is a nuisance if leaked; a signing key for a payment authorisation system is a critical control whose compromise can have immediate financial and legal consequences.

The two failure modes in secrets management are well understood, even if they remain common in practice. The first is centralisation without resilience: all secrets stored in a single vault, which becomes both a single point of failure and a high-value target. The second is distribution without governance: secrets scattered across application configuration files, environment variables, CI/CD pipeline secrets stores, cloud-provider key management services and developer laptops, with no consistent policy for rotation, expiry or revocation.

A sovereign multi-cloud architecture must navigate between these failure modes. The answer is not a single global vault, nor an ungoverned proliferation of secrets stores, but a federated secrets management architecture with consistent policy, consistent rotation practices, and clear zone-based boundaries.

HashiCorp Vault [10] is the most widely deployed open-source secrets management platform in enterprise cloud environments, and its architecture is well-suited to sovereign multi-cloud deployments. A typical sovereign deployment operates one Vault cluster per sovereign zone, configured with zone-appropriate storage backends (commonly using Raft integrated storage or a cloud provider key-value store) and zone-appropriate seal mechanisms (hardware security modules, cloud KMS services, or Shamir secret sharing distributed across zone operators). Vault’s replication capabilities — performance replication and disaster recovery replication — allow secrets defined in a primary cluster to be made available to secondary clusters in other zones, with careful control over which namespaces and secret paths are replicated and which are zone-local. The seal/unseal operation is a critical control: in a sovereign architecture, the unsealing material should be held by operators within the zone, not by a global platform team, so that a single actor outside the zone cannot unilaterally access zone-local secrets.

Vault’s dynamic secrets capability deserves specific attention. Rather than storing a static database credential that is read by an application and used indefinitely, Vault’s database secrets engine generates a unique credential for each consumer, valid for a configurable lease period. When the lease expires, the credential is automatically revoked. This eliminates entire classes of risk: long-lived credentials stolen from configuration files or environment variables are no longer useful to an attacker after a short window. The audit log records every issuance and revocation, providing an accurate account of which systems had access to which databases at which times.

IBM Secrets Manager, built on the open-source HashiCorp Vault engine, provides the same capabilities in the IBM Cloud context and integrates with IBM’s broader identity and key management ecosystem. For organisations operating regulated workloads on IBM Cloud or IBM Sovereign Core, IBM Secrets Manager provides a managed path to strong secrets management without the operational overhead of self-managed Vault infrastructure.

The integration of Vault with Kubernetes deserves specific mention because Kubernetes is the primary deployment substrate for most modern cloud-native workloads and presents its own secrets management challenges. Native Kubernetes secrets are base64-encoded values stored in etcd, the cluster’s key-value store. By default, they are not encrypted at rest (though encryption at rest can be configured). They can be accessed by any workload with the right Kubernetes RBAC permissions. Applications frequently read them into environment variables, which can be exposed through process listing, container introspection or application crashes. The Secrets Store CSI driver [11] addresses this by mounting secrets from an external provider — Vault, AWS Secrets Manager, Azure Key Vault — directly into pods as ephemeral volumes, without the secret ever being stored as a Kubernetes secret object. The secret is fetched at pod startup, resides in memory, and is not persisted anywhere within the cluster. This is a materially stronger posture than the Kubernetes-native approach, particularly for secrets whose compromise would have severe consequences.

Secrets management architecture across sovereign zones

IBM Key Protect [31] provides managed key management on IBM Cloud, backed by FIPS 140-2 Level 3 certified hardware security modules that ensure encryption keys never exist in plaintext outside the HSM boundary. Key Protect integrates natively with IBM Cloud services — Object Storage, Block Storage, Databases, Kubernetes Service and others — through envelope encryption, where a root key held in the HSM wraps the data encryption keys used by each service. For sovereign deployments, Key Protect’s regional isolation guarantees that root keys are generated, stored and used exclusively within the selected IBM Cloud region, satisfying data residency requirements without requiring the organisation to operate its own HSM infrastructure. IBM Guardium Data Encryption and Guardium Key Lifecycle Manager [32] extend these capabilities beyond the IBM Cloud boundary, providing transparent data encryption for on-premises file systems, databases and storage volumes, and centralised key lifecycle management across hybrid environments. Guardium Key Lifecycle Manager supports KMIP and serves as a bridge for organisations that must manage encryption keys across IBM, third-party and legacy systems from a single governance point.

The Key Management Interoperability Protocol (KMIP) warrants mention as a standards layer for key lifecycle management that sits above any particular vendor implementation. KMIP is an OASIS standard that defines a client/server protocol for communicating key management operations — create, get, register, destroy, revoke — in a vendor-neutral way. Organisations that need to manage encryption keys across heterogeneous systems, including HSMs from different manufacturers and key management services from different cloud providers, can use KMIP to interact with all of them through a common interface. In a sovereign context, KMIP-compatible key management — whether provided through Guardium Key Lifecycle Manager, Vault’s KMIP secrets engine, or a dedicated HSM appliance — allows organisations to avoid lock-in to a single provider’s key management implementation and to demonstrate that their key lifecycle management meets a recognised standard.

13.5 Non-human identities: agents, pipelines and services

Human identities are the visible face of the identity problem, but they are a minority of the identities that matter in a modern multi-cloud estate. The majority are non-human: service accounts used by applications to authenticate to databases and message brokers, pipeline credentials used by CI/CD systems to deploy code, and — increasingly — identities used by AI agents and automation workflows to act on behalf of the organisation. The agentic operations model described throughout this book depends on AI agents having identities that are trusted, scoped and auditable. Without a principled approach to non-human identities, the assurance properties of the whole architecture degrade.

The traditional approach to non-human identities — a service account with a long-lived password stored in a configuration file or passed as an environment variable — is increasingly recognised as inadequate. Long-lived credentials are the primary mechanism by which cloud environments are compromised: they are leaked in code repositories, captured in logs, exfiltrated from configuration files, or simply never rotated after an initial deployment. The replacement is workload identity: a mechanism by which the platform itself issues short-lived credentials to workloads based on their verified identity, without any pre-shared password.

Cloud providers have developed platform-native implementations of this concept. AWS IAM Roles for Service Accounts (IRSA) allows Kubernetes pods running on Amazon EKS to assume AWS IAM roles without using any long-lived credentials: the Kubernetes service account is associated with an IAM role via an OIDC trust relationship, and when a pod needs AWS credentials, the AWS SDK exchanges a short-lived Kubernetes service account token for short-lived AWS credentials from the AWS STS service [12]. Azure Workload Identity provides the same mechanism for AKS clusters on Azure, using the Azure Entra ID federated identity credentials system [13]. Google Workload Identity Federation extends this concept to non-Google environments, allowing workloads on-premises or on other clouds to authenticate to Google Cloud using OIDC tokens from a trusted external IdP [14]. All three mechanisms share the same essential property: no long-lived credential is stored anywhere; identity is proved dynamically by the platform at the time it is needed.

The challenge in a multi-cloud estate is that these mechanisms are provider-specific. A workload that needs to interact with services on AWS, Azure and GCP must somehow acquire credentials for each. SPIFFE (the Secure Production Identity Framework For Everyone) and its reference implementation SPIRE (the SPIFFE Runtime Environment), maintained by the Cloud Native Computing Foundation (CNCF) [15], address this by defining a vendor-neutral workload identity standard. SPIFFE defines the SVID (SPIFFE Verifiable Identity Document), a short-lived, cryptographically signed document that asserts a workload’s identity in a portable format (typically an X.509 certificate or a JWT). SPIRE implements the attestation and issuance machinery: it observes workload metadata — the Kubernetes service account, the node identity, the container image, the process environment — and issues SVIDs to workloads that meet the configured attestation criteria. Cloud provider-specific integrations can then exchange an SVID for cloud provider credentials, creating a unified identity substrate that works across providers.

In the context of this book’s agentic operations model, SPIFFE/SPIRE has a particular role. Concert agents, Orchestrate workflow executors and Bob all require non-human identities that can be verified by the systems they interact with. Those identities must be scoped to what each agent is permitted to do: a diagnostic agent that collects metrics and traces does not need, and must not have, the credentials that would allow it to modify infrastructure or access production databases. A change-execution agent that invokes Ansible playbooks needs write access to automation APIs but should not have access to the signing keys used to authorise financial transactions. Scoping non-human identities this precisely requires the same principle-of-least-privilege discipline applied to human identities, expressed in terms of short-lived credentials whose scope reflects the agent’s authorised function.

The audit requirements for agent actions are non-negotiable. Every action taken by an agent must be traceable to an identity — which agent, running on which platform — and to an authorisation event: a specific policy that permitted the action, evaluated at the time the action was taken, not merely assumed to be permitted because the agent has not been explicitly denied. This requirement for event-level traceability of agent actions is what connects the identity and access plane to the Governance and Audit Plane described in Chapter 4. The identity event stream — credential issuances, SVID attestations, role assumptions — must flow into the same audit fabric as operational events, so that a post-incident investigation can reconstruct exactly which agents acted, in what capacity, under what policy authorisation, and at what time.

13.6 Certificate lifecycle management at scale

Expired TLS certificates are a recurring source of operational disruption that is entirely avoidable with systematic lifecycle management. The failure mode is well known: a certificate issued for twelve months, noted in a ticket, tracked in a spreadsheet, and then missed when the renewal reminder gets buried in email. Services begin returning TLS handshake errors. Monitoring may not catch it immediately if the certificate expiry path is not exercised in synthetic tests. By the time operators diagnose the cause, a service that was fully functional has been unavailable for minutes or hours — an avoidable incident that reflects poorly on operational maturity and, in regulated environments, may trigger reporting obligations.

At the scale of a large enterprise multi-cloud estate, the number of certificates is not a few dozen but potentially several thousand: every Kubernetes cluster has certificates for the API server and for the components that form the control plane; every service mesh has certificates for each workload participating in mTLS; every load balancer and ingress controller presents a certificate to external clients; internal services authenticate to each other using certificates. No manual tracking system scales to this.

The ACME (Automated Certificate Management Environment) protocol, developed in the context of Let’s Encrypt [16], provides the foundation for automated certificate issuance and renewal. ACME defines a standard protocol by which a certificate requester proves control over a domain — through DNS records, HTTP challenges or TLS-ALPN challenges — and receives a signed certificate from a Certificate Authority (CA). The protocol is designed for automation: no human needs to be involved in the normal certificate lifecycle. cert-manager [17], a CNCF project, implements ACME and other issuance mechanisms as a Kubernetes operator. It watches Certificate and Issuer resources in Kubernetes, issues certificates automatically against configured CAs — Let’s Encrypt for public-facing services, an internal CA for internal services — and renews them before they expire, without any manual intervention. cert-manager is the de facto standard for automated certificate management in Kubernetes environments and integrates with Vault’s PKI secrets engine, enabling organisations to use their own internal CA infrastructure through the same automated mechanism.

Sovereign zones require internal PKI, not merely public CA certificates, for a significant proportion of their certificate infrastructure. Mutual TLS (mTLS) between services within a sovereign zone should use certificates issued by an internal CA whose root of trust is held within that zone. This is not merely an operational preference; it reflects the requirement that the cryptographic trust infrastructure for regulated services should be under the organisation’s own control, not dependent on a public CA whose root certificates are distributed globally and whose operations may be subject to jurisdictions outside the organisation’s sovereign boundary. Vault’s PKI secrets engine functions as a full-featured internal CA, capable of issuing intermediate CAs and leaf certificates, enforcing certificate policies (key type, maximum validity period, permitted domains), and rotating the CA infrastructure automatically.

Certificate transparency (CT) logs — public, append-only logs of all certificates issued by participating CAs — serve a governance function beyond security. Organisations that monitor CT logs for certificates issued under their domain names can detect unauthorised issuance: a certificate for a subdomain that should not exist, or a certificate issued by an unexpected CA, appears in the CT logs and can be identified. IBM Certificate Manager provides tooling for certificate lifecycle management within the IBM Cloud ecosystem, integrating with IBM Cloud’s certificate tracking, ordering and automatic renewal capabilities. In a hybrid deployment, the combination of cert-manager for Kubernetes-native workloads, Vault PKI for internal mTLS infrastructure, and IBM Certificate Manager for IBM Cloud-hosted services provides comprehensive coverage across the estate.

13.7 Access governance and the audit trail

Having the right technical controls — federated identity, privileged access management, secrets management and certificate lifecycle automation — is necessary but not sufficient. Regulators and risk functions also expect that access is reviewed periodically, that it is appropriate given current roles and responsibilities, and that no single identity has the ability both to approve and to execute a sensitive change. These expectations collectively fall under the heading of access governance, and they require organisational processes as well as technical controls.

Segregation of duties (SoD) is the principle that sensitive workflows should require at least two separate actors: one who initiates or approves, and one who executes. In an infrastructure context, this means that the engineer who authors a Terraform change should not be the only person who can approve and apply that change. In a financial services context, it means that the person who can approve a payment threshold change should not also have the ability to apply that change directly to the production system. DORA, ISO/IEC 27001:2022 and the Sarbanes-Oxley Act (SOX) [18] all implicitly or explicitly require SoD controls for sensitive processes, and auditors consistently test whether the technical controls actually enforce these requirements or whether they exist only on paper.

Entitlement management — the governance process by which access entitlements are requested, approved, provisioned, reviewed and revoked — must be systematic at scale. IBM Security Verify provides identity governance capabilities including access request workflows, role management, segregation of duties analysis and access certification campaigns, which are the periodic structured processes by which managers and system owners confirm that the access held by individuals in their purview is still appropriate [19]. These certification campaigns are the operational mechanism by which the “access reviews at regular intervals” required by ISO/IEC 27001:2022 and DORA are actually conducted. Without tooling that surfaces entitlements in an accessible form, aggregates them by system and user, and tracks the outcome of review decisions, access certification degrades into a box-ticking exercise that provides little genuine assurance.

IBM OpenPages, IBM’s governance, risk and compliance platform, provides the framework for managing access-related risks, controls and obligations at the enterprise level [20]. In an integrated architecture, OpenPages holds the authoritative record of access controls and their regulatory mapping: which control addresses which DORA or ISO/IEC 27001 requirement, what evidence is expected to demonstrate that the control is operating effectively, and what the consequence of control failure is. That record is populated, in part, by automated evidence ingested from the technical control systems — IAM logs, PAM session records, Vault audit logs, cert-manager events — so that the compliance posture reflected in OpenPages corresponds to actual operational behaviour rather than to assertions that have not been independently verified.

Concert’s topology model plays a role in access governance that is easily overlooked. Concert, as described in Chapter 14, maintains a continuously updated map of the relationships between applications, services, infrastructure components and environments. That topology, combined with identity and access data, makes it possible to answer questions that are difficult to answer from identity systems alone: “Which identities have access to systems that process regulated data in sovereign zone B?” “Which service accounts have write access to the message broker that feeds the financial reporting pipeline?” “Are there any lateral paths by which an identity that should only have access to the development environment can reach production systems?” Concert’s relational view of the estate turns access governance from a per-system exercise into an estate-wide analysis.

The identity event stream — the flow of authentication events, authorisation decisions, credential issuances and access grants that the technical controls produce — is a first-class source of operational and audit signals. Failed authentication events that cluster around a specific service may indicate an attack or a misconfigured credential. Privilege escalations that occur at unusual times may warrant investigation. Credentials issued to an agent for a scope that is broader than the agent’s normal function may indicate policy misconfiguration. IBM Security QRadar and similar SIEM platforms ingest these events and correlate them with other operational signals, surfacing patterns that might otherwise remain invisible in the volume of routine access traffic. In a sovereign architecture, the SIEM must respect zone boundaries: events from sovereign zone A should be retained and analysed within zone A’s boundaries, with only aggregated or anonymised signals crossing zone boundaries.

13.8 Encoding identity policy as code

The disciplines described in this chapter — federated identity configuration, IAM role definitions, Vault policies, cert-manager issuers, access entitlement rules — must themselves be managed as code if they are to be reliable, reviewable and consistent. This is not merely a matter of convenience; it is a prerequisite for sovereign operations at scale.

Chapter 11 established infrastructure as code as the spine of the estate, providing a version-controlled, executable description of desired state. Identity infrastructure belongs on the same spine. Terraform providers exist for AWS IAM, Azure Entra ID, Google Cloud IAM, HashiCorp Vault and Kubernetes RBAC. An organisation that manages its IAM roles and policies as Terraform means that every access grant is a pull request with a diff, a reviewer and a reason. A change that adds a new trust relationship to a cloud IAM role is visible in the Git history with the name of the engineer who proposed it, the reviewer who approved it, and the timestamp of the merge. That visibility is qualitatively different from the typical cloud console workflow, where the same change is a click that may leave only a sparse API event in the cloud provider’s audit log.

Policy-as-code tools add enforcement on top of this declarability. Open Policy Agent (OPA) [21], the CNCF policy engine, can evaluate proposed IAM changes against organisation-specific rules before they are applied: a policy that states “no role in sovereign zone B may trust an OIDC issuer other than the zone-B identity provider” will reject any Terraform plan that introduces a non-compliant trust relationship, at CI time, before it reaches production. Conftest, the tool for applying OPA policies to structured configuration data, can evaluate Terraform plan output, Kubernetes manifests, Helm values and Vault policy documents against the same policy library. This creates a consistent policy enforcement layer across the diverse formats that identity infrastructure inhabits.

Ansible complements Terraform for identity infrastructure that is not natively managed by a Terraform provider. Group membership management in Active Directory, LDAP attribute synchronisation, Vault mount configuration, and the rotation of long-lived credentials that cannot yet be replaced by dynamic issuance are all tasks that can be expressed as Ansible playbooks, making them repeatable and auditable. IBM Ansible Certified Content Collections provide tested, maintained playbooks for IBM infrastructure components, including Vault-integrated credential management.

GitOps for identity means that access policy changes are subject to the same review and approval workflow as application changes. A developer who needs write access to a new S3 bucket does not raise a ticket to an IAM administrator; they open a pull request that adds the appropriate IAM policy to the relevant Terraform module, which is reviewed for correctness and policy compliance, merged by an approver with appropriate authority, and applied automatically by the GitOps pipeline. The entire lifecycle is recorded in Git and in the pipeline’s audit log. Emergency access — the “break-glass” scenario where an operator needs elevated access immediately during a severe incident — is handled through a separate, time-bounded process that is also expressed in code: a Vault policy that issues a specific privileged credential for a configurable duration, with mandatory session recording and an automatic post-incident review to confirm that the elevation was appropriate.

The connection back to Chapter 11’s treatment of IaC is not merely structural. The same reason that infrastructure managed in Git is more trustworthy than infrastructure managed through console clicks applies to identity: an identity infrastructure managed in Git, reviewed by humans, checked by policy engines and applied by automation is more trustworthy than one managed by a series of manual operations whose history is distributed across email threads, tickets and individuals’ memories. In a sovereign estate where regulators expect documented, auditable evidence of access controls, that trustworthiness is not optional.

13.9 Securing the sovereign control plane

Chapter 4 introduces the cross-cloud control plane — Concert, watsonx Orchestrate and the supporting observability and automation components — as the architectural centre of sovereign operations, and section 4.10 addresses the structural concern that this plane represents a single point of compromise across the entire multi-cloud estate. This section provides the identity and access detail behind that architectural argument: the specific authentication, authorisation, credential management and monitoring controls that make the distributed trust model concrete.

Machine-to-machine authentication

Every interaction between the control plane and a sovereign zone — Concert querying a zone’s Instana instance, Orchestrate dispatching an automation action to a zone’s Ansible Automation Platform, a governance check calling a zone-local OPA endpoint — is a machine-to-machine communication that must be mutually authenticated. The architecture mandates mTLS for all such interactions, with short-lived X.509 certificates issued through SPIFFE/SPIRE [15]. Each control plane component receives a SPIFFE Verifiable Identity Document (SVID) whose trust domain is scoped to the control plane’s own identity namespace. Zone-local components receive SVIDs from their own zone’s SPIRE server. Cross-boundary trust is established through SPIRE federation — explicitly configured trust bundles between the control plane’s trust domain and each zone’s trust domain — rather than through a shared root of trust [15]. Certificate lifetimes are measured in hours, not months; rotation is automatic and transparent to application logic.

For credential issuance to target zones, the control plane does not hold static API keys or service account tokens. Instead, it uses the dynamic credentials pattern described in section 13.4: HashiCorp Vault’s cloud secrets engines generate temporary, scoped tokens for AWS, Azure, GCP and IBM Cloud on demand, valid only for the specific action and resource scope requested [10]. When the action completes, the lease is revoked. The control plane’s Vault policy explicitly prohibits issuing credentials with administrative scope or unbounded lifetime. This is the mechanical implementation of the “no standing privilege” principle described in Chapter 4: the control plane can request only what it needs, only when it needs it, and only for as long as the action requires.

Human access to the control plane

Human operators who administer the control plane itself — configuring topology discovery, adjusting correlation rules, managing integration credentials — represent the highest-risk access path. A compromised administrator account is the most direct route to control plane subversion.

The architecture requires FIDO2/WebAuthn hardware security keys for all human authentication to control plane administrative interfaces [33]. Phishing-resistant authentication is not optional; password-based and SMS-based second factors are explicitly prohibited for control plane access. Administrative sessions are time-bounded, require re-authentication for privilege escalation, and are recorded in their entirety for audit review. For the most sensitive operations — modifying the control plane’s trust relationships with sovereign zones, rotating the control plane’s own root credentials, or altering break-glass access procedures — a two-person authorisation rule applies: the action must be proposed by one administrator and approved by a second, each authenticating independently with their own hardware key.

Anomaly detection and continuous monitoring

Authentication and authorisation controls prevent known-bad access patterns, but they cannot detect novel attack vectors or slow-moving insider compromises. The control plane’s own access logs — every API call, every credential request, every administrative action — must be treated as a first-class security telemetry stream, ingested into the observability plane and subjected to anomaly detection.

The relevant signals include: geographic origin of access requests (an administrative session originating from an unexpected jurisdiction warrants immediate investigation); time-of-day patterns (control plane administrative access outside normal operating windows); action frequency (a sudden spike in credential requests for a particular zone may indicate automated credential harvesting); and scope escalation patterns (repeated requests for broader-than-normal credential scopes). IBM QRadar SIEM and Instana’s infrastructure monitoring can both ingest control plane audit logs; the anomaly detection models should be trained on baseline access patterns established during normal operations and should alert on deviations that exceed configurable thresholds [34].

The control plane’s audit trail must be immutable and zone-local. Control plane logs are written to append-only storage within the sovereign zone where the control plane is deployed, signed with the zone’s own keys, and retained according to the zone’s data governance policy. No external party — including the control plane vendor — should have the ability to modify, delete, or access these logs without the customer’s explicit authorisation. This is the final link in the chain: the control plane is monitored by the same observability and governance infrastructure that it orchestrates, creating a closed loop of accountability.

13.10 Post-quantum cryptography and cryptographic agility

The cryptographic primitives that underpin every control described in this chapter — TLS certificates, JWT signatures, Vault seal keys, SPIFFE SVIDs, HSM-protected encryption keys — share a common vulnerability. RSA and elliptic curve cryptography (ECC), the two families of asymmetric algorithms on which virtually all current key exchange and digital signature operations depend, are vulnerable to Shor’s algorithm running on a sufficiently capable quantum computer. The timeline for such a machine is debated, but the consensus among cryptographers has narrowed: both the US National Security Agency and the UK National Cyber Security Centre have issued guidance advising organisations to begin planning their transitions to quantum-resistant algorithms now [24].

The urgency stems from the “harvest now, decrypt later” attack vector, which is already operational: adversaries with long time horizons are collecting encrypted network traffic and data stores today, expecting to decrypt the material when quantum computing capability matures. For sovereign operations handling classified data, financial records with decades-long retention requirements, or health records, this is a present architectural concern, not a future one. Data encrypted today with RSA-2048 or ECDH and stored by an adversary will be readable the moment a cryptographically relevant quantum computer becomes available. The protection window of the encryption must exceed the sensitivity window of the data, and for long-lived regulated data that arithmetic is already unfavourable.

NIST post-quantum standards

The National Institute of Standards and Technology concluded its Post-Quantum Cryptography standardisation process in August 2024, publishing three initial standards [25]. FIPS 203 specifies ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), formerly known as CRYSTALS-Kyber, as the primary standard for key encapsulation — the operation by which two parties establish a shared secret over an untrusted channel. FIPS 204 specifies ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly CRYSTALS-Dilithium, as the primary standard for digital signatures. FIPS 205 specifies SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), based on SPHINCS+, as a hash-based signature scheme that provides a conservative alternative resting on different mathematical foundations from the lattice-based schemes. IBM Research played a significant role in the development of the lattice-based algorithms: several members of the CRYSTALS team are IBM researchers, and the underlying lattice problems — Module Learning With Errors for ML-KEM and Module Short Integer Solution for ML-DSA — were refined through IBM’s cryptography research programme [26]. This is not incidental; it reflects IBM’s strategic commitment to post-quantum security across its product portfolio.

Cryptographic agility as an architectural principle

The transition from classical to post-quantum algorithms is not a one-time migration; it is the latest instance of a recurring pattern. DES gave way to 3DES and then AES; MD5 and SHA-1 gave way to SHA-2 and SHA-3. Each transition was more painful than necessary because algorithms were hard-coded into applications, protocols and hardware, requiring re-engineering rather than reconfiguration.

Cryptographic agility is the architectural discipline of ensuring that the next transition does not require re-architecting systems. In practice, this means abstracting cryptographic operations behind well-defined interfaces so that algorithm choice is a configuration parameter, not a code change. Application code calls a “sign” or “encrypt” function; the underlying algorithm is selected by policy. Key management systems maintain a cryptographic inventory: a registry of which algorithms are in use, where, by which systems, protecting which data classifications. That inventory is the prerequisite for any systematic migration, because you cannot transition what you cannot enumerate.

The migration path from RSA and ECC to PQC will, for most organisations, pass through a hybrid phase. Hybrid key exchange, already implemented in TLS libraries including OpenSSL 3.x, combines a classical exchange (ECDH) with a post-quantum exchange (ML-KEM) so that the resulting shared secret is secure against both classical and quantum attacks. If the post-quantum algorithm proves flawed, the classical algorithm provides a fallback; if a quantum computer breaks the classical algorithm, the post-quantum component provides protection. Sovereign architectures should adopt hybrid key exchange for all new deployments while planning the retrofit of existing services.

Post-quantum cryptographic migration path showing hybrid classical-PQC key exchange during transition

Confidential computing and data-in-use protection

Classical encryption protects data at rest and in transit, but data must be decrypted before it can be processed. In a cloud environment, this exposes data in memory to anyone with sufficient host-level privilege — including the cloud provider’s own operators. For sovereign operations, this is a structural gap: data sovereignty during processing depends on the trustworthiness of the operator.

Confidential computing addresses this gap through hardware-based trusted execution environments (TEEs) that protect data in use. Intel Software Guard Extensions (SGX) [27] create hardware-enforced enclaves in which code and data are encrypted in memory, inaccessible to any software outside the enclave including the operating system and hypervisor. AMD Secure Encrypted Virtualisation with Secure Nested Paging (SEV-SNP) [28] provides confidential virtual machines whose memory is encrypted with a key managed by the AMD security processor. IBM takes a distinctive approach with Hyper Protect Virtual Servers, combining hardware isolation on IBM Z and LinuxONE processors with a hardened, attestable runtime environment [29]. IBM Hyper Protect Crypto Services extend this to key management, providing a cloud-hosted HSM built on FIPS 140-2 Level 4 certified hardware with the critical property that even IBM’s own cloud operators cannot access the key material — a property IBM terms “Keep Your Own Key” (KYOK). For sovereign operations, this means that the most sensitive workloads can run in a public or hybrid cloud without the provider having any technical ability to access the data, even under compulsion.

Homomorphic encryption

A more radical approach is homomorphic encryption (HE), which allows computation on encrypted data without decryption. IBM has been a leading contributor through HElib, an open-source library implementing the Brakerski-Gentry-Vaikuntanathan (BGV) and Cheon-Kim-Kim-Song (CKKS) schemes [30]. The limitations remain significant — HE operations are orders of magnitude slower than plaintext equivalents, and only certain computation classes map efficiently onto HE schemes. However, for sovereign use cases such as cross-zone analytics where regulated data must never leave its zone in plaintext, privacy-preserving computations on health or financial data, and federated machine learning on sensitive datasets, HE offers a path to deriving value from data that regulation would otherwise make inaccessible.

Implications for sovereign zone architecture

The convergence of these technologies has direct consequences for sovereign zone architecture. Key management infrastructure must be quantum-ready: HSMs deployed in sovereign zones must support PQC algorithms, and key lifecycle policies must accommodate the larger key sizes of lattice-based schemes. Certificate lifecycle management, as described in section 13.6, must accommodate algorithm transitions: internal PKI must issue certificates with PQC signature algorithms, and the certificate inventory must track which algorithms protect which services. Sovereign zones with the longest data retention requirements — financial records under MiFID II, health records under national regulations, classified material under government security frameworks — should prioritise PQC adoption first, because the data they protect today must remain confidential for the longest period into the quantum future.

Cryptographic agility must be a first-class architectural requirement. Every new system deployed in a sovereign zone should abstract its cryptographic operations behind interfaces that allow algorithm substitution without service redesign. The cryptographic inventory should sit alongside the infrastructure inventory in the configuration management database, and policy-as-code checks should enforce that no new deployment introduces hard-coded algorithm dependencies. Confidential computing should be the default for the most sensitive data classifications, with TEE-based processing mandated by sovereign zone policy for workloads handling data whose compromise would have the gravest consequences.

Key Takeaways

Bridge to Chapter 14 — IBM Concert Architecture

Identity, secrets and access form the control fabric that makes everything else in the sovereign operations architecture trustworthy. The zero-copy integration substrate depends on access policies to enforce data governance at source. Sovereign zones depend on identity isolation to maintain their boundaries. Agentic operations depend on scoped, auditable non-human identities to remain within their authorised domains. The Governance and Audit Plane depends on the identity event stream as a first-class source of audit evidence. Without a principled approach to these foundations, the assurances promised by the rest of the architecture are hollow.

The chapter has moved from the conceptual — identity as the new perimeter — through the structural (federated identity stacks and sovereign zone constraints) to the operational (secrets management, workload identity, certificate lifecycle and access governance) and the procedural (encoding identity policy as code). The consistent thread is that identity and access, like infrastructure, must be managed declaratively, reviewed carefully and enforced automatically.

Chapter 14 turns to IBM Concert, the platform that sits at the centre of this book’s vision of sovereign, agentic operations. Concert depends directly on the identity and access infrastructure described here: its topology model is only as reliable as the identity data that populates it, its agents operate under the non-human identity disciplines set out in section 13.5, and its governance integrations consume the audit trail that identity systems produce. Understanding how Concert is architected requires understanding the identity fabric on which it rests.

References

[1] National Institute of Standards and Technology, “Zero Trust Architecture,” NIST Special Publication 800-207, U.S. Department of Commerce, Gaithersburg, MD, Aug. 2020. [Online]. Available: https://doi.org/10.6028/NIST.SP.800-207

[2] Cybersecurity and Infrastructure Security Agency, “Zero Trust Maturity Model, Version 2.0,” CISA, Washington, DC, Apr. 2023. [Online]. Available: https://www.cisa.gov/zero-trust-maturity-model

[3] European Parliament and of the Council, “Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA),” Official Journal of the European Union, vol. L 333, pp. 1–79, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554

[4] European Parliament and of the Council, “Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2),” Official Journal of the European Union, vol. L 333, pp. 80–152, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555

[5] European Parliament and of the Council, “Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (GDPR),” Official Journal of the European Union, vol. L 119, pp. 1–88, Apr. 2016. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

[6] D. Hardt, Ed., “The OAuth 2.0 Authorization Framework,” IETF, RFC 6749, Oct. 2012. [Online]. Available: https://www.rfc-editor.org/rfc/rfc6749

[7] M. Jones and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” IETF, RFC 6750, Oct. 2012. [Online]. Available: https://www.rfc-editor.org/rfc/rfc6750

[8] International Organization for Standardization and International Electrotechnical Commission, “Information Security, Cybersecurity and Privacy Protection — Information Security Management Systems — Requirements,” ISO/IEC 27001:2022, Oct. 2022. [Online]. Available: https://www.iso.org/standard/82875.html

[9] CyberArk, “CyberArk 2024 Identity Security Threat Landscape Report,” CyberArk Software Ltd., Newton, MA, 2024. [Online]. Available: https://www.cyberark.com/threat-landscape

[10] HashiCorp, “Vault Documentation,” HashiCorp, San Francisco, CA. [Online]. Available: https://developer.hashicorp.com/vault/docs

[11] Cloud Native Computing Foundation, “Secrets Store CSI Driver,” CNCF. [Online]. Available: https://secrets-store-csi-driver.sigs.k8s.io

[12] Amazon Web Services, “IAM Roles for Service Accounts,” AWS Documentation. [Online]. Available: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html

[13] Microsoft, “Azure Workload Identity,” Microsoft Azure Documentation. [Online]. Available: https://azure.github.io/azure-workload-identity/docs

[14] Google Cloud, “Workload Identity Federation,” Google Cloud Documentation. [Online]. Available: https://cloud.google.com/iam/docs/workload-identity-federation

[15] Cloud Native Computing Foundation, “SPIFFE and SPIRE Projects,” CNCF. [Online]. Available: https://spiffe.io

[16] R. Barnes, J. Hoffman-Andrews, D. McCarney, and J. Kasten, “Automatic Certificate Management Environment (ACME),” IETF, RFC 8555, Mar. 2019. [Online]. Available: https://www.rfc-editor.org/rfc/rfc8555

[17] Cloud Native Computing Foundation, “cert-manager Documentation,” CNCF. [Online]. Available: https://cert-manager.io/docs

[18] U.S. Congress, “Sarbanes-Oxley Act of 2002,” Public Law 107-204, U.S. Government, Washington, DC, Jul. 2002. [Online]. Available: https://www.govinfo.gov/content/pkg/PLAW-107publ204/pdf/PLAW-107publ204.pdf

[19] IBM, “IBM Security Verify,” IBM Corporation. [Online]. Available: https://www.ibm.com/products/verify-identity

[20] IBM, “IBM OpenPages GRC Platform,” IBM Corporation. [Online]. Available: https://www.ibm.com/products/openpages-with-watson

[21] Open Policy Agent, “OPA Documentation,” CNCF. [Online]. Available: https://www.openpolicyagent.org/docs/latest

[22] European Parliament and Council of the European Union, “Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework (eIDAS 2.0),” Official Journal of the European Union, vol. L, Apr. 2024. [Online]. Available: https://eur-lex.europa.eu/eli/reg/2024/1183

[23] PCI Security Standards Council, “Payment Card Industry Data Security Standard (PCI DSS), Version 4.0,” PCI SSC, Wakefield, MA, USA, Mar. 2022. [Online]. Available: https://www.pcisecuritystandards.org/document_library/

[24] National Security Agency, “Announcing the Commercial National Security Algorithm Suite 2.0,” NSA Cybersecurity Advisory, Washington, DC, Sep. 2022. [Online]. Available: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0ALGORITHMS.PDF

[25] National Institute of Standards and Technology, “Post-Quantum Cryptography: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA),” U.S. Department of Commerce, Gaithersburg, MD, Aug. 2024. [Online]. Available: https://csrc.nist.gov/projects/post-quantum-cryptography

[26] R. Avanzi, J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler, and D. Stehlé, “CRYSTALS-Kyber: Algorithm Specifications and Supporting Documentation,” NIST PQC Round 3 Submission, 2021. [Online]. Available: https://pq-crystals.org/kyber/

[27] Intel Corporation, “Intel Software Guard Extensions (Intel SGX) Developer Guide,” Intel, Santa Clara, CA. [Online]. Available: https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/overview.html

[28] Advanced Micro Devices, “AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More,” AMD White Paper, Santa Clara, CA, Jan. 2020. [Online]. Available: https://www.amd.com/en/developer/sev.html

[29] IBM, “IBM Hyper Protect Virtual Servers and Hyper Protect Crypto Services,” IBM Corporation. [Online]. Available: https://www.ibm.com/products/hyper-protect-virtual-servers

[30] S. Halevi and V. Shoup, “HElib — An Implementation of Homomorphic Encryption,” IBM Research. [Online]. Available: https://github.com/homenc/HElib

[31] IBM Corporation, “IBM Key Protect for IBM Cloud: Managed Key Management Service,” IBM Documentation, Armonk, NY, USA, 2024. [Online]. Available: https://cloud.ibm.com/docs/key-protect

[32] IBM Corporation, “IBM Guardium Data Encryption and Guardium Key Lifecycle Manager,” IBM Documentation, Armonk, NY, USA, 2024. [Online]. Available: https://www.ibm.com/products/guardium-data-encryption

[33] FIDO Alliance, “FIDO2: WebAuthn & CTAP — Overview,” FIDO Alliance, Beaverton, OR, USA, 2024. [Online]. Available: https://fidoalliance.org/fido2/

[34] IBM Corporation, “IBM QRadar SIEM — Product Documentation,” IBM, Armonk, NY, USA, 2025. [Online]. Available: https://www.ibm.com/docs/en/qradar-siem

Sovereign Cloud Operations: AI-Driven Management of Sovereign Estates © 2026 by Alan Hamilton is licensed under CC BY-SA 4.0