Sovereign identity federation is the practice of establishing cross-organisation authentication and authorisation trust using open standards (SAML 2.0, OpenID Connect, OAuth 2.0) hosted entirely on infrastructure subject to the jurisdiction chosen by the operating organisation, rather than delegated to a third-party provider whose legal domicile may expose identity assertions and access logs to foreign compulsory process. For European regulated-sector organisations, the distinction is not architectural preference; it is a legal compliance requirement that existing deployments built on Azure AD B2B or Okta may already be violating.
The Jurisdictional Problem With US-Controlled Identity Providers
Routing authentication flows through Azure AD or Okta places the resulting identity assertions, session tokens and federation metadata under the legal reach of the US CLOUD Act (2018) and FISA Section 702. This is true regardless of whether the underlying business data is stored in Europe.
When an organisation configures Azure AD B2B guest accounts for a partner organisation, the authentication assertion, the access token and the audit log entry that records the successful login are all created and stored within Microsoft’s tenant infrastructure. Microsoft is a US-controlled entity. Under the CLOUD Act, US law enforcement can compel Microsoft to produce those records through a domestic warrant, without notifying the organisation or its partner, and without requiring a Mutual Legal Assistance Treaty request to the relevant EU member state.
The European Data Protection Supervisor addressed this directly: “Organisations that rely on a foreign-controlled identity provider are, in effect, handing a foreign government the keys to their access control system. The authentication log is not merely metadata; it is a complete map of who accessed what, when, and from where.” (EDPS Opinion 2/2023 on the use of Microsoft 365 by EU institutions.)
According to ENISA’s Threat Landscape 2023, identity and access management weaknesses featured in more than 60 percent of significant incidents reported under NIS frameworks, making the security and jurisdictional integrity of the identity layer one of the highest-priority controls for regulated organisations.
Building a Sovereign Federation Hub on Open Standards
A self-hosted federation hub using open-source software can replicate all cross-organisation trust functionality of Azure AD B2B without routing a single authentication assertion through US-controlled infrastructure.
The two primary open-source candidates are Keycloak (maintained by Red Hat and the wider open-source community) and Authentic (developed by Entrouvert, a French cooperative that specialises in public-sector federation middleware). Both implement SAML 2.0, OpenID Connect and OAuth 2.0 natively. The choice between them turns on organisational context: Keycloak offers broader IAM capabilities, including fine-grained authorisation policies, a rich extension API and extensive connector coverage; Authentic is purpose-built for inter-organisational SAML federation in the French and European public-sector ecosystem and aligns closely with government interoperability frameworks such as RGI (Référentiel Général d’Interopérabilité).
A sovereign federation hub architecture for cross-organisation access works as follows. Each participating organisation runs its own identity provider, configured to expose a SAML 2.0 or OIDC metadata endpoint. The federation hub, running Keycloak or Authentic on infrastructure hosted in a jurisdiction of the operating organisation’s choosing (including Swiss data centres under the revised Swiss Federal Act on Data Protection, FADP), acts as a broker: it accepts inbound authentication assertions from member organisations, validates them against registered metadata, maps attributes according to a pre-agreed schema and issues new assertions to relying-party applications. No external SaaS platform handles any step of this flow.
| Capability | Azure AD B2B federation | Sovereign Keycloak/Authentic hub |
|---|---|---|
| Cross-org SAML/OIDC trust | Yes, via Microsoft Entra ID | Yes, via self-hosted broker |
| Authentication log jurisdiction | US (CLOUD Act, FISA 702 applicable) | Operating organisation’s chosen jurisdiction |
| Attribute release control | Partially configurable, Microsoft-mediated | Fully configurable, organisation-owned policy |
| GDPR data residency guarantee | Contractual, subject to legal override | Structural, no third-party override possible |
| PQC token signing migration path | Dependent on Microsoft roadmap | Organisation-controlled, can adopt ML-DSA independently |
Integrating eIDAS 2.0 EUDI Wallet as a Trust Anchor
The eIDAS 2.0 Regulation (EU) 2024/1183 establishes the European Digital Identity Wallet (EUDI Wallet) as a government-issued, citizen-controlled credential store. For public-sector federation, it offers a sovereign alternative to password-based or proprietary MFA for primary authentication.
The EUDI Wallet presents identity attributes as Verifiable Credentials using the OpenID for Verifiable Credential Issuance (OID4VCI) and OpenID for Verifiable Presentations (OID4VP) protocols. This means a sovereign federation hub running Keycloak can act as an OID4VP relying party: a civil servant or healthcare professional presents their EUDI Wallet on their mobile device, the hub validates the government-issued credential against the national trust registry, and then issues a standard SAML 2.0 assertion or OIDC ID token to the downstream service provider.
The European Commission’s eIDAS Expert Group has noted: “The EUDI Wallet must be seen not as a replacement for existing federated identity infrastructure but as an additional trust anchor that can be incorporated into existing SAML and OpenID Connect flows.” (ARF for the EUDI Wallet, v1.4.) This backward-compatibility framing is critical: existing SAML-connected applications in a ministry or hospital group require no modification when the federation hub handles the translation layer.
Attribute Release Policy, Consent and Audit Architecture Under GDPR and NIS-2
A sovereign federation hub must operationalise GDPR Article 5’s data minimisation obligation at the protocol level, not as an afterthought. Every attribute released from an identity provider to a relying party must be governed by a written attribute release policy (ARP) that specifies the legal basis for each attribute, the subset of attributes required by each service, and the retention period for assertion logs.
In Keycloak, this is implemented through protocol mappers scoped to individual client configurations: a payroll application receives employee ID and department, not date of birth or home address. Authentic implements similar controls through its federation configuration interface. The ARP should be version-controlled and stored as a configuration-as-code artefact, making it directly auditable.
NIS-2 Directive (EU) 2022/2555 Article 21 requires essential and important entities to implement access control, multi-factor authentication and audit logging as baseline security measures. The audit log architecture for a federation hub must record, at minimum: the identifier of the authenticating user (pseudonymised where the processing purpose allows), the identity provider that issued the assertion, the relying party that received it, the attributes released, the timestamp and the session identifier. These logs must be tamper-evident (append-only, cryptographically chained or written to a WORM-compliant store) and must be retained in alignment with the organisation’s incident response and supervisory reporting obligations.
Post-Quantum Migration for SAML Assertions and OIDC Tokens
SAML 2.0 assertions are XML documents signed with RSA or ECDSA. JSON Web Tokens (JWTs) used in OIDC and OAuth 2.0 flows are signed with RS256 (RSA-PKCS1v1.5), RS384, ES256 (ECDSA-P256) or similar classical algorithms. All of these are vulnerable to a cryptographically relevant quantum computer running Shor’s algorithm.
NIST estimates that a quantum computer capable of breaking RSA-2048 could exist within 10 to 15 years (NIST IR 8547, 2024). This frames the harvest-now-decrypt-later threat window for authentication logs: an adversary that captures signed assertions and federation metadata today can potentially decrypt and forge them in the future, reconstructing who held access to what systems at what time.
NIST published FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium) in 2024 as the primary post-quantum digital signature standard. The migration path for a sovereign federation hub is tractable precisely because the organisation controls its own signing key infrastructure. The recommended approach is a hybrid transition: add an ML-DSA secondary signature to SAML assertions and JWTs alongside the existing ECDSA signature. Relying parties that support ML-DSA can validate the quantum-safe signature; legacy relying parties continue to validate the classical signature. Once the relying-party ecosystem is upgraded, the classical signature can be dropped. Organisations using Azure AD or Okta cannot implement this migration on their own timeline; they must wait for the provider’s roadmap.
The average cost of a data breach reached USD 4.88 million in 2024, the highest figure in the IBM report’s history (IBM Cost of a Data Breach Report 2024). Identity-related breaches, including token theft and session hijacking, are a leading breach vector. Quantum-safe token signing is a forward hedge against the category of attack that will become dominant as quantum capability matures.
DORA Operational Resilience for a Shared Federation Hub
DORA Regulation (EU) 2022/2554 entered into application on 17 January 2025. For financial entities that operate a sovereign federation hub as a shared authentication service for multiple member organisations, DORA introduces specific obligations around ICT resilience and concentration risk.
A federation hub serving ten banks, insurers or investment firms simultaneously is a single point of failure for the authentication layer of all of them. If it fails, none of them can authenticate staff, partners or clients. DORA Article 28 requires financial entities to identify and manage ICT concentration risk, and a shared IAM service with no geographic redundancy is a textbook example of unmanaged concentration risk.
The required controls for a DORA-compliant sovereign federation hub operating as a shared service include: active-active deployment across at least two geographically separate data centres with independent network paths; independent Hardware Security Module (HSM) infrastructure at each site holding a copy of the signing key material, synchronised through an approved key management protocol; recovery time objectives (RTOs) and recovery point objectives (RPOs) formally documented in the ICT business continuity plan of each connected entity; and annual failover tests with documented results provided to each entity’s management body. If the hub is operated by a managed service provider rather than in-house, DORA’s third-party ICT risk framework (Articles 28 to 44) applies in full, including the requirement to register the provider as a critical ICT third-party service provider if it meets the systemic significance thresholds set by the European Supervisory Authorities.
FAQ
Does using Azure AD B2B guest accounts create CLOUD Act exposure even if no personal data is stored in Azure?
Yes. The authentication assertions, session tokens and access logs generated during the federation flow are themselves data held by a US-controlled provider. Under the CLOUD Act, Microsoft can be compelled to produce these records regardless of where the underlying business data resides. The logs reveal who accessed which resource, when, and from which network, making them operationally and legally sensitive in their own right.
What is the practical difference between Keycloak and Authentic for a sovereign federation hub?
Keycloak is a full-featured IAM platform with broad integration coverage, fine-grained authorisation and a large extension ecosystem, making it suitable for organisations with diverse application portfolios. Authentic, developed by Entrouvert, is purpose-built for inter-organisational SAML federation in the French and European public-sector context, with native alignment to national eGovernment interoperability frameworks. The choice depends on breadth of integration requirements versus depth of public-sector federation specificity.
When should a CISO start migrating SAML and OIDC signing keys to ML-DSA?
The migration case is driven by the harvest-now-decrypt-later threat, not by quantum computer availability. Adversaries can capture signed authentication tokens and federation metadata today. For tokens whose significance extends beyond five years (audit logs, long-lived access records), the exposure window is open now. NIST FIPS 204 published in 2024 provides a stable migration target. CISOs should begin by inventorying all signing keys, then deploy hybrid ECDSA-plus-ML-DSA signing for new assertions while legacy relying parties are upgraded.
How does the EUDI Wallet integrate with existing SAML service providers?
The EUDI Wallet uses OID4VP (OpenID for Verifiable Presentations) to present government-issued attributes to a relying party. A sovereign federation hub such as Keycloak can act as an OID4VP relying party, validate the wallet presentation against the national trust registry and then translate the validated attributes into a SAML 2.0 assertion for downstream service providers. Existing SAML applications require no modification; the federation hub handles all protocol translation.
How should a shared sovereign federation hub be structured to satisfy DORA concentration risk requirements?
The hub must be deployed in an active-active configuration across at least two geographically separate sites with independent network and HSM infrastructure. Each connected financial entity must document the hub in its ICT business continuity plan with defined RTOs and RPOs. Annual failover tests must be conducted and results provided to each entity’s management. If operated as a managed service, the provider must be assessed under DORA’s third-party ICT risk framework and potentially registered with the European Supervisory Authorities as a critical ICT third-party provider.