Published on
August 18, 2026
Every certificate your organization trusts traces back to a single object: the root CA key. If that key leaks, an attacker can mint valid credentials for any server, user or device inside your perimeter, and recovery means rebuilding trust from zero across every laptop, appliance and workload.
That is why mature PKI programs keep the root offline: powered down, disconnected from every network, and woken only for rare, scripted ceremonies. This guide walks the full setup in five steps, then covers the operational trap that silently breaks more PKIs than any attacker ever did.
Why offline, at a glance
The root exists to do one job: sign the certificates of a small number of subordinate issuing CAs, publish an occasional revocation list, and otherwise stay dark while day to day issuance happens on the online issuing CAs.
Attack surface collapses.
A root that never touches a network can only be attacked through physical access and ceremony procedure, both of which you control completely.
Blast radius shrinks.
A compromised issuing CA is a bad week: revoke it at the root, stand up a replacement, reissue. A compromised root is an existential event.
Auditors expect it.
National cybersecurity agencies, including ANSSI and the UK NCSC, converge on the same design: a two tier hierarchy with an offline root and online issuing CAs, kept as simple as the organization allows.
Step 1: Design the hierarchy on paper
Resist the urge to boot anything until the architecture is written down.
Create a structure with an offline root signing a small number of issuing CAs, split by function rather than whim: one for TLS, one for user and device authentication, perhaps one for code signing.
• Lifetimes: a common internal pattern gives the root ten to twenty years, issuing CAs five to ten, and end entity certificates one year or less, with shorter leaf lifetimes preferred wherever automation exists.
• Algorithms: RSA 3072 or an elliptic curve today, with a clear path to hybrid and post quantum signatures, because a root created in 2026 will still anchor trust in 2040.
• Policy: write the certificate policy and practice statement, even a short one. Auditors ask for it, and drafting it exposes gaps early.
Step 2: Protect the key in hardware
A root key generated in software on a laptop is a root key that lived, however briefly, in swappable memory on a general purpose machine. Serious deployments do better.
Take control of your PKI infrastructure
See how Evertrust simplifies certificate lifecycle management.
Get Started
• Generate and keep the key in an HSM certified against FIPS 140 Level 3 or an equivalent scheme, so the private key never leaves hardware in usable form.
• Enforce quorum control, for example three of five smart cards, with custodians drawn from different teams.
• Split the backups: tamper evident envelopes, separate safes, ideally separate buildings.
• On a tight budget, smaller hardware form factors exist, but the quorum principle stays non negotiable.
Step 3: Publish CDP and AIA before the first signature
Here is the step first timers discover too late. Every certificate the root signs embeds two sets of URLs: the CRL distribution point (CDP), where relying parties fetch the root's revocation list, and the authority information access (AIA) field, where they fetch the root certificate itself. Those values are baked into subordinate certificates forever, so they need to be correct in advance.
• Stand up the HTTP publication point first, on stable, neutral hostnames independent of any single server's fate.
• On Microsoft AD CS, edit the default CDP and AIA settings before issuing the subordinate certificate.
• Validate the chain afterwards with certutil and pkiview, or the equivalent on your stack.
Step 4: Run the ceremony like it matters
A key ceremony is theater with legal weight. The output is not just a key; it is evidence that lets you answer an auditor or a court with documents instead of memories.
• Script everything: every command, every expected output, every decision point.
• Assemble the cast: an operator, a separate script reader, quorum custodians, and at least one independent witness, with cameras rolling if your compliance regime expects it.
• Work clean: a room without network drops, a machine built from verified media.
• Execute and seal: generate the key in the HSM, create the root certificate, sign the issuing CA certificates, generate the first CRL, export only public artifacts, sign the log, seal the materials, power down.
Step 5: Put the root CRL on a calendar
Now the counterintuitive part. An offline root still owes the world one recurring artifact: its certificate revocation list. Relying parties check it to confirm no issuing CA was revoked, and it carries an expiry date. When it lapses, chain validation fails across the estate, in confusing ways, because nothing was revoked and nothing visibly changed. Expired root CRLs are among the most common self inflicted PKI outages.
• Give the root CRL a long validity, commonly six to twelve months.
• Put the renewal ceremony on a calendar with alerts to multiple owners.
• Monitor the published CRL's freshness from the outside, exactly as you monitor certificate expiry.
Between ceremonies, the root lives as sealed hardware in a safe with a documented chain of custody, waking once or twice a year: to renew the CRL, sign a new issuing CA, or rehearse recovery with the quorum present. A recovery procedure nobody practiced is a hope, not a plan.
How Evertrust can help
Stream, our PKI platform, runs multi tier hierarchies with offline roots, integrates with HSMs such as the Thales Luna line, including firmware with native ML KEM and ML DSA support, and keeps every key under the customer's exclusive control. Its certification under the ANSSI CSPN scheme reflects the same philosophy this guide teaches.
Horizon, our lifecycle platform, watches the things humans forget: CRL freshness, subordinate expiry, and chain health across the estate, with alerting wired to real owners.
See it against your own estate: request a demo of Horizon and Stream at evertrust.io.
Your offline root questions, answered
Q: How often does the root come online?
A: Typically once or twice a year: CRL renewal, signing a new issuing CA, or a recovery rehearsal. Anything more frequent suggests work that belongs on an issuing CA.
Q: Can a powered off virtual machine serve as the root?
A: It is better than an always on root, but a VM image is copyable in ways sealed hardware is not. If you accept the tradeoff, compensate with strict image custody and HSM backed keys.
Q: What if the root CRL already expired?
A: Convene the ceremony, reissue the CRL with a fresh validity window, republish to every CDP location, then fix the process: calendar, alerts, and external freshness monitoring.
Q: Is cross signing relevant here?
A: Yes, at transition time. When the root itself eventually changes, for age or algorithm, cross signing lets the new root inherit trust gradually while clients update, avoiding a flag day.
