A sovereign certificate authority (CA) is a public key infrastructure component that an organisation owns, operates and controls entirely within its own legal and technical boundary, without delegating root trust or certificate issuance to a third-party commercial CA subject to foreign law. For European regulated organisations, this distinction is not architectural preference: it is a legal and operational necessity when the alternative is dependence on US-headquartered providers reachable by CLOUD Act orders, FISA 702 directives or domestic national security letters.
The Legal Exposure of US-Based Commercial Certificate Authorities
Any CA that is incorporated in or operationally controlled from the United States is legally compelled to comply with US government demands under the CLOUD Act (2018), regardless of where its infrastructure physically sits. This means that DigiCert, Sectigo, and the Internet Security Research Group (which operates Let’s Encrypt) can be served with orders requiring cooperation that European data protection law cannot block.
The exposure goes beyond data disclosure. A court order could compel a commercial CA to issue a rogue subordinate certificate or revoke an organisation’s certificates on short notice, disrupting every TLS-secured service that depends on them. The CAB/Forum Baseline Requirements require public CAs to revoke mis-issued certificates within 24 hours for critical cases, a timeline that offers no practical recourse for an organisation whose operations are interrupted.
For healthcare, finance and public-sector organisations processing data under GDPR, NIS-2 or DORA, the dependency on a foreign-controlled PKI root also creates a demonstrable gap in Article 32 GDPR technical measures, NIS-2 Article 21 supply-chain controls, and DORA’s ICT risk management obligations under Article 6.
Designing an Air-Gapped Sovereign Root CA Hierarchy
A properly structured sovereign PKI uses a three-tier hierarchy: an offline Root CA, one or more offline Policy CAs, and online Issuing CAs that handle day-to-day certificate requests. The Root CA private key must never reside on a networked system.
Key ceremony requirements under BSI and ANSSI frameworks
Both BSI TR-02102 and the French ANSSI RGS framework require that root key generation occurs in a physically controlled environment with a formal key ceremony. The ceremony must be witnessed, scripted, recorded and signed off by at least two authorised officers. Key material is generated on a Hardware Security Module (HSM) that meets FIPS 140-2 Level 3 or Common Criteria EAL 4+ and is never exported in plaintext. The ceremony script, witness signatures and audit log form part of the Certificate Practice Statement (CPS) that BSI or ANSSI auditors will inspect.
Open-source tooling that satisfies these requirements includes EJBCA Community (developed by PrimeKey, now Keyfactor), which supports HSM integration via PKCS#11, formal CA role separation, and audit logging suitable for regulated environments. Step-CA from Smallstep and Red Hat Dogtag are viable alternatives for organisations with lighter issuance volumes or existing Red Hat infrastructure dependencies.
Subordinate CA structure for operational isolation
Issuing CAs should be segmented by certificate type: one for internal TLS, one for S/MIME and document signing, one for device and machine identity. This limits blast radius if an issuing CA key is compromised and allows different revocation policies and audit trails per certificate class. Each issuing CA certificate is signed during an offline Root CA ceremony and is itself stored with HSM protection.
Certificate Lifecycle Management Without SaaS Dependency
Replacing SaaS-delivered PKI requires implementing every lifecycle function on-premises: issuance, renewal, revocation publication, and automated provisioning.
OCSP and CRL infrastructure
Revocation information must be available at all times. The CRL Distribution Point (CDP) and OCSP responder URLs embedded in every issued certificate must resolve to internally hosted endpoints. OCSP responders should be replicated across availability zones to prevent a single-point revocation failure. CRL sizes for large internal deployments can exceed practical limits for some clients; delta CRLs published every few hours mitigate this without requiring full CRL downloads on every validation event.
Automated provisioning via ACME (RFC 8555)
Manual certificate renewal is the single most common cause of preventable TLS outages. The ACME protocol (RFC 8555) defines a standard challenge-response mechanism that allows workloads to obtain and renew certificates without human intervention. EJBCA Community includes a native ACME implementation; Step-CA was designed around ACME from its initial release. Deploying an internal ACME endpoint with short-lived certificates (90-day validity or less) and automatic renewal at 60 percent of lifetime eliminates the operational risk of expiry-driven outages that commercial SaaS renewal services are typically engaged to prevent.
Regulatory Integration: NIS-2, DORA and eIDAS 2.0
A sovereign CA is not only a security control; it is a compliance asset that must be wired into the organisation’s formal governance frameworks.
| Regulation | Relevant obligation | How sovereign PKI addresses it |
|---|---|---|
| NIS-2 Directive, Article 21 | Supply-chain risk management for ICT services and components | Removes dependency on foreign-controlled CA; PKI supply chain is fully internal and auditable |
| DORA, Article 6 | ICT risk management framework including cryptographic controls | Sovereign CA lifecycle is documented, tested and included in the ICT asset register |
| eIDAS 2.0 (EU) 2024/1183 | Qualified certificate issuance for legally binding transactions | Where qualified certificates are required, the CA must comply with ETSI EN 319 411 and seek TSP registration |
| GDPR, Article 32 | Technical measures ensuring ongoing confidentiality and integrity | Sovereign PKI ensures encryption keys and certificates remain under EU-controlled jurisdiction |
ENISA has stated: “The revised eIDAS 2.0 framework creates binding obligations for Trust Service Providers to apply ETSI EN 319 411 policy requirements, making informal PKI arrangements legally insufficient for qualified certificate issuance in the EU.” Organisations issuing certificates for legally binding purposes must align their CPS with ETSI EN 319 411-1 (LCP/NCP) or 411-2 (QCP) profiles and prepare for conformity assessment by an accredited auditor.
Migration from a Commercially Rooted PKI
The migration from a commercial CA to a sovereign internal CA follows a parallel-operation model that avoids any period of broken trust.
Phase one establishes the sovereign Root CA and at least one issuing subordinate CA while all existing commercial certificates remain valid. Phase two distributes the new root certificate to all managed endpoints via Group Policy Object or MDM before any sovereign-issued certificate reaches those endpoints. Phase three re-issues internal service certificates from the sovereign issuing CA and validates full chain resolution in every affected application, load balancer and API gateway. Phase four allows commercial certificates covering internal services to expire naturally; revocation is not necessary and avoids disruption risk.
Externally accessible portals that require trust in browsers used by external parties require a different approach. These endpoints typically retain a publicly trusted certificate from a commercial CA, while the sovereign CA governs all internal east-west traffic, S/MIME signing, VPN authentication and machine identity. Partner integrations that rely on mutual TLS must be managed individually, with explicit sovereign root distribution negotiated as part of the integration agreement.
Post-Quantum Certificate Profiles and the NIST Migration Timeline
The sovereign CA architecture must be designed today to accommodate post-quantum certificate profiles, because retrofitting a CA hierarchy for new signature algorithms is operationally complex and cannot be done quickly under pressure.
NIST published its first finalised post-quantum cryptography standards in August 2024, including FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium), the primary algorithm for digital signatures including X.509 certificate signing. BSI has stated: “Organisations that store sensitive data encrypted with classical algorithms today must assume that a sufficiently capable quantum adversary could decrypt that data in the future. Migration to post-quantum algorithms is therefore not optional; it is a matter of timing.”
The practical implication for sovereign PKI is twofold. First, the issuing CA software must support ML-DSA key generation and certificate signing; EJBCA Community has published roadmap commitments for PQC algorithm support aligned with NIST finalisation. Second, the transition period requires hybrid X.509 certificates that carry both a classical signature (RSA-4096 or ECDSA P-384 as specified in BSI TR-02102) and an ML-DSA signature, so that relying parties that do not yet support PQC can still validate the classical chain while quantum-capable clients validate the post-quantum chain. The IETF is standardising hybrid certificate formats through ongoing work in the LAMPS working group, and organisations building sovereign PKI now should track that output to avoid a second migration cycle.
IBM’s Cost of a Data Breach Report 2023 found that the global average cost of a data breach reached USD 4.45 million, a 15 percent increase over three years. For regulated European organisations, a PKI compromise or jurisdiction-forced certificate disclosure would trigger breach notification obligations under GDPR Article 33 and NIS-2 Article 23, amplifying the financial and reputational cost well beyond the technical remediation effort. A sovereign CA removes the foreign-law vector entirely and gives the organisation full control over its cryptographic trust infrastructure, from root key generation to post-quantum algorithm migration, within a governance framework it owns.
FAQ
Can a sovereign internal CA issue certificates trusted by end-user browsers without relying on a commercial root?
For internal services, yes: the sovereign root certificate is distributed via Group Policy or MDM to all managed devices and browsers, establishing trust without any commercial CA involvement. For externally accessible portals requiring public browser trust, a hybrid approach is common: a public CA covers the public-facing TLS endpoint while the sovereign CA governs all internal service-to-service and client authentication certificates.
What does “air-gapped Root CA” mean in practice and why does it matter for regulated organisations?
An air-gapped Root CA is a signing system that is permanently disconnected from any network. It is powered on only during formally witnessed key ceremonies to sign subordinate CA certificates or certificate revocation lists. Because the root private key never touches a networked system, it cannot be exfiltrated remotely. BSI TR-02102 and ANSSI guidelines both treat offline root key storage as a baseline control for high-assurance PKI.
How does the ACME protocol (RFC 8555) work in an on-premises sovereign PKI context?
ACME (RFC 8555) is an automation protocol that allows servers to request, renew and revoke certificates without manual intervention. In a sovereign PKI, tools such as Step-CA or the EJBCA Community ACME implementation expose an internal ACME endpoint. Workloads authenticate via DNS-01 or HTTP-01 challenges against the internal CA, receiving short-lived certificates that are automatically renewed before expiry. This removes the manual renewal risk that causes unplanned outages.
Does operating a sovereign CA require eIDAS 2.0 Trust Service Provider registration?
Not for purely internal certificate use. eIDAS 2.0 (Regulation (EU) 2024/1183) and ETSI EN 319 411 policy requirements apply to Trust Service Providers that issue qualified certificates for public relying parties. An organisation operating a sovereign CA solely for its own internal TLS, S/MIME or device authentication falls outside mandatory TSP registration. However, organisations in the legal or financial sector that issue certificates used in legally binding transactions should evaluate whether qualified certificate obligations apply to their specific use case.
What is the practical migration sequence from a commercially rooted PKI to a sovereign internal CA?
The migration has four phases: first, deploy the sovereign Root CA and at least one issuing subordinate CA in parallel with the existing commercial PKI; second, distribute the new root certificate to all managed endpoints via Group Policy or MDM; third, re-issue internal service certificates from the sovereign CA while commercial certificates remain valid, validating trust chain resolution in all affected applications; fourth, allow commercial certificates to expire naturally. Partner integrations and browser-accessible portals with external users require separate planning, typically retaining a public CA for those specific endpoints.