Identity & Access complete

• Ad-hoc account creation. Each application or server maintains its own local user database. When a new employee joins, administrators manually create accounts in each system - often with inconsistent usernames and passwords.
• Shared credentials. Teams routinely share a single admin account for cloud consoles, databases, or SaaS tools. Password rotation, if it happens at all, requires coordinating across everyone who knows the current password.
• No authentication governance. No deliberate decisions have been made about how users authenticate. Each system uses its own defaults, typically password-only, with no organisation-wide policy.
• No joiners-movers-leavers process. When an employee leaves, their accounts may remain active for weeks or months because no one owns the offboarding checklist.

Shared accounts eliminate accountability. If a data breach occurs, the organisation cannot determine which individual performed the malicious or negligent action. This makes forensic investigation unreliable, regulatory notification inaccurate, and legal liability difficult to assign.

From a regulatory standpoint, GDPR Art 32 requires "appropriate technical and organisational measures" to ensure security proportionate to the risk. Operating without basic identity controls falls well below any reasonable interpretation of "appropriate."

At this level, sovereignty is not even a consideration - the organisation lacks the foundational controls required to reason about who has access to what. Identity sovereignty presupposes that an identity system exists in the first place.

• Single cloud IdP. All employees authenticate through a provider like Microsoft Entra ID (formerly Azure AD), Google Workspace, or Okta. The directory, authentication engine, and policy enforcement all run on the provider's infrastructure.
• Provider-managed MFA. Multi-factor authentication is enabled, typically via the provider's mobile app or SMS-based codes. Hardware tokens or FIDO2 keys are not yet in use.
• No data-residency control. The identity directory and associated metadata (login timestamps, device fingerprints, group memberships) are stored in regions chosen by the provider, often in the United States.
• Limited portability. The organisation cannot easily migrate to a different identity provider. Group structures, conditional access policies, and application integrations are tightly coupled to the specific provider's API and data model.

Identity is the control plane for everything else. Whoever controls identity controls who can access data, deploy infrastructure, and approve changes. When that control plane is entirely managed by an external provider - particularly one subject to foreign jurisdiction - the organisation's operational sovereignty is fundamentally dependent on that provider's continued availability, goodwill, and legal posture.

Under the US CLOUD Act, American authorities can compel US-headquartered providers to disclose data - including identity metadata - regardless of where it is stored. This means an organisation's directory information, authentication logs, and group memberships could be accessed without the organisation's knowledge or consent.

• "We use SSO, so we control identity." SSO federated through a cloud IdP merely centralises authentication - it does not give the organisation control over the identity store itself.
• "The provider is ISO 27001 certified." Certification demonstrates the provider's internal controls, not the organisation's sovereignty over its own data. The organisation remains a tenant, not an operator.

• Negotiated DPA with specifics. The Data Processing Agreement goes beyond the provider's standard template. It includes jurisdiction-specific data-residency commitments (e.g., identity data processed only within the EU/Switzerland), sub-processor change notification with objection rights, and audit clauses that permit third-party assessments.
• Federation with organisational control. SAML 2.0 or OIDC protocols are configured so that authentication flows use organisation-owned domain names and certificates. This provides protocol-level portability - applications integrate with a federation endpoint the organisation controls, even though the underlying IdP is still cloud-managed.
• Independent log retention. Audit logs from the identity provider are streamed to an organisation-controlled SIEM (e.g., Splunk, Elastic, or a managed Swiss SIEM provider). This ensures that authentication events are preserved independently of the provider's retention policies and access controls.
• Documented access reviews. Periodic access certification campaigns are conducted using provider tooling, but the results are exported and stored in an independent GRC platform for regulatory evidence and long-term retention.

The fundamental limitation of Level 2 is that contractual obligations are only as strong as the enforcement mechanisms behind them. Key risks include:

• Jurisdictional override. A foreign court order or government directive can compel the provider to act contrary to contractual commitments. The CLOUD Act, for example, explicitly overrides contractual data-residency restrictions for US-headquartered providers.
• Unilateral service changes. Providers routinely update terms of service, deprecate features, or modify data-processing practices. While DPA clauses may require notification, the organisation's recourse is typically limited to termination - which, given migration complexity, is rarely practical.
• Audit limitations. Even robust audit clauses rarely grant the organisation real-time technical inspection of the provider's identity infrastructure. Audits are periodic, scoped, and often conducted by the provider's chosen auditors.

For many organisations, Level 2 represents a reasonable balance between sovereignty and operational pragmatism. It is appropriate when:

• The organisation's regulatory environment accepts contractual safeguards as a valid risk-mitigation measure
• The identity data being processed is not classified as highly sensitive or subject to strict localisation mandates
• The organisation lacks the internal expertise to operate a self-managed identity platform reliably
• A credible migration plan to Level 3 exists and can be triggered if the risk posture changes

• Bring Your Own Identity (BYOI). The organisation defines the identity lifecycle - creation, modification, suspension, deletion - independently of any cloud provider. Provisioning to cloud services is a downstream action, not the originating event.
• Hardware-based authentication. FIDO2 security keys or smartcards are mandatory for privileged accounts. This eliminates phishing-susceptible factors (SMS, push notifications) for the most sensitive access paths.
• Jurisdiction-aware access policies. Conditional access rules evaluate the user's geographic location, device compliance status, and the classification of the resource being accessed. A user attempting to access sensitive data from an unapproved jurisdiction is blocked or required to complete additional verification.
• Portable identity data. The identity directory can be exported in standard formats (LDIF, SCIM) and restored to a different platform. The organisation has tested this migration path and confirmed that user accounts, group memberships, and access policies survive the transition.

Self-managed identity infrastructure demands operational maturity:

• High availability. The IdP is a Tier-0 service - if it is unavailable, no one can authenticate to anything. Clustering, geographic redundancy, and tested failover procedures are essential.
• Patch management. Self-managed software requires timely security patching. Keycloak, for example, has a regular release cadence that must be tracked and applied.
• Monitoring and alerting. Authentication failures, configuration changes, and anomalous login patterns must be monitored continuously. The organisation should have a dedicated identity operations function or a managed-service arrangement with a sovereignty-respecting provider.
• Key management. SAML signing keys, OIDC client secrets, and FIDO2 attestation certificates are critical secrets that require proper lifecycle management (rotation, revocation, backup).

At Level 3 the organisation has achieved substantive identity sovereignty. It controls where identity data is stored, how authentication is performed, and under which conditions access is granted. Cloud providers receive only the minimum information necessary via federation tokens - they do not hold the master copy of the directory.

The primary remaining risk is operational: the federation links to cloud services still represent touch points that could be disrupted by provider action. A cloud provider could, for example, modify its federation implementation in a way that breaks interoperability, or impose new requirements that conflict with the organisation's policies.

The distinguishing characteristic of Level 4 is zero external dependency for identity operations. This goes beyond self-hosting the IdP (Level 3) to encompass every supporting service:

• Certificate authority. The organisation operates its own internal CA for TLS certificates used in identity flows, eliminating dependency on public CA providers for internal authentication.
• MFA infrastructure. FIDO2 attestation, TOTP seed generation, and hardware token provisioning are handled entirely in-house. No authentication step requires a call to an external service.
• DNS and service discovery. Internal identity services can resolve and route without external DNS dependency, ensuring authentication continues during internet outages or DNS-based attacks.
• HSM-backed key management. All identity-critical cryptographic material - SAML/OIDC signing keys, token encryption keys, CA private keys - resides in hardware security modules under the organisation's physical and administrative control.

Level 4 organisations are positioned to participate in decentralised identity ecosystems. The W3C Verifiable Credentials (VC) and Decentralised Identifiers (DID) standards enable trust relationships between organisations without requiring a shared centralised identity provider.

Practical applications include:

• Employee credential portability. Issuing verifiable credentials that employees can present to partner organisations without the issuing organisation maintaining a real-time federation link.
• Supply-chain identity. Verifying the identity of vendors, contractors, and partners using cryptographically verifiable credentials rather than shared Active Directory trusts or SAML federations.
• Regulatory attestation. Issuing machine-verifiable credentials that attest to compliance status, professional certifications, or security clearances.

Decentralised identity is not mandatory at Level 4 - the criterion requires either implementation or a documented capability to implement. The core requirement is that the organisation's identity infrastructure is architecturally capable of participating in decentralised trust models.

Level 4 demands the highest level of internal operational capability:

• Dedicated IAM engineering team. The organisation needs staff with deep expertise in identity protocols (SAML, OIDC, SCIM, LDAP), cryptography, and infrastructure operations. This is typically a team of 3-5 engineers for a mid-sized organisation.
• 24/7 identity operations. The IdP is a Tier-0 service. Outages must be resolved within minutes, not hours. On-call rotations and automated failover are mandatory.
• Security research awareness. Without a cloud provider's security team monitoring for identity-layer vulnerabilities, the organisation must track CVEs, zero-days, and protocol-level attacks affecting its identity stack independently.
• Regular resilience testing. The annual isolation test - verifying that authentication works without external connectivity - is a defining practice at Level 4. Organisations should also conduct red-team exercises specifically targeting the identity infrastructure.

Full identity autonomy is appropriate for organisations that:

• Process highly classified or sovereignty-sensitive data where any external identity dependency is unacceptable
• Operate in regulated sectors (defence, critical infrastructure, banking) where regulators explicitly require self-managed identity controls
• Have experienced or are specifically threatened by state-level adversaries capable of compelling cloud providers to modify authentication behaviour
• Possess the engineering talent and operational maturity to sustain a self-managed identity platform at enterprise scale

For many organisations, Level 3 (Controlled) provides sufficient sovereignty with lower operational risk. Level 4 should not be pursued as a default aspiration - it should be a deliberate decision driven by a specific threat model and risk appetite, backed by a credible operational plan.

At Level 4 the organisation has no external identity dependencies. No foreign government can compel a provider to disclose directory data or modify authentication behaviour, because no such provider exists in the architecture. The organisation's identity sovereignty is limited only by its own operational competence.