ADCS Disaster Recovery Backup: What Must Be Included

Our broader guidance on enterprise PKI consistently comes back to the same point: disaster recovery has to be designed in from day one, not bolted on after an incident, and it has to cover redundant infrastructure, documented recovery plans, and HSM-protected keys as a complete package. This post translates that into something you can actually inventory for AD CS specifically: every artifact required to rebuild your root CA, every issuing CA, and every service that depends on them.

This is a different scope from How to Back Up Microsoft ADCS Correctly, which covers the mechanics of backing up a single CA server. This post is the hierarchy-wide inventory: what a real DR plan needs to contain across your entire PKI, not just what one backup job needs to capture.

TL;DR: Key Takeaways

A DR plan covers the entire hierarchy, not one CA: root and every issuing CA each need their own complete artifact set, and losing any single CA in the chain without a recovery path breaks trust for everything beneath it.
The root CA belongs in your inventory even though it’s rarely online: it’s the least frequently touched, most consequential part of your PKI to lose, and its recovery artifacts, especially HSM key recovery and ceremony documentation, are easy to under-prioritize precisely because the root itself sits idle most of the time.
Service dependencies are where most DR plans have silent gaps: NDES, CES/CEP, RADIUS/NPS integrations, and custom enrollment tooling each have their own recovery artifacts that a CA-level backup never touches.
Templates and AD Configuration container objects need explicit inclusion, even though they technically live in Active Directory, a complete ADCS DR plan accounts for them directly rather than assuming general AD backup coverage is sufficient.
An inventory only becomes a real DR capability once it’s tested: cataloging every artifact is the starting point, confirming you can actually rebuild from that catalog, on a schedule, is what makes it disaster recovery rather than a documentation exercise.

How This Differs From a Routine Backup

A backup job protects a specific system. A disaster recovery plan protects a capability, in this case, the ability to issue and validate certificates across your entire organization, which depends on more systems working together than any single backup job covers. An issuing CA’s backup can be flawless and your DR posture can still fail if the root CA’s key recovery process was never tested, or if NDES’s registration authority certificate was never included anywhere.

Building a real ADCS DR inventory means working outward from each individual CA to everything that CA structurally depends on or feeds into: the parent above it, the templates and AD objects it references, the services built on top of it, and the publication infrastructure relying parties use to validate what it issues. Miss any layer and you can have a technically successful CA restore that still doesn’t restore actual certificate-based operations for your organization.

Root CA Artifacts Inventory

CA database, certificate, and private key backup: captured via certutil -backup for the database and certificate, with the private key handled through your HSM vendor’s own backup or cloning mechanism if the root is HSM-backed, which it should be.
Full registry configuration export: capturing CRL periods, audit filter settings, and publication URL templates specific to the root, none of which travel with the database backup.
CAPolicy.inf as it existed at root generation and at each renewal: a plain file, easy to lose, and directly relevant to reconstructing exactly how the root was configured.
Key ceremony and any subsequent renewal ceremony documentation: the original generation ceremony script and witness records, plus documentation from every certificate-only renewal performed since, this is both a recovery artifact and a compliance artifact.
Documented location and access procedure for offline, air-gapped storage: where the root server or its removable media physically lives, who has authorized access, and what the access procedure requires, this is itself part of the recovery artifact set, not just operational security policy.

Issuing CA Artifacts Inventory

The same core set as the root, per issuing CA: database and certificate backup, private key or HSM key recovery process, full registry export, and CAPolicy.inf, repeated individually for every issuing CA in your hierarchy, not assumed to be uniform across them.
Each CA’s specific issuance list: captured with certutil -CATemplates, since which templates a given issuing CA is configured to issue against is CA-specific state, not something that comes back automatically with a database restore.
HSM partition or token assignment details per CA, if multiple issuing CAs share HSM infrastructure, document which partition or token belongs to which CA explicitly, this is easy to get wrong during a stressed recovery effort if it isn’t written down in advance.
Parent chain reference for each issuing CA, documenting exactly which CA above it in the hierarchy it depends on, so recovery sequencing (parent before child) is unambiguous during an actual incident.

Certificate Templates and AD Configuration Artifacts

Certificate template objects from Active Directory, exported via ldifde or PowerShell from the Certificate Templates container in the Configuration partition, since no CA-level backup captures these.
Template permissions and enrollment agent configurations, which live in AD alongside the templates themselves and are just as invisible to a CA backup.
Enrollment Services, AIA, CDP, and Certification Authorities container objects, the AD objects your CAs publish to and depend on for chain-building and revocation checking across your domain.
NTAuth store membership, confirming which CAs are authorized for certificate-based Kerberos authentication, losing this silently breaks smart card and certificate-based logon even if every CA itself is fully restored.

Service Dependency Artifacts

NDES registration authority (RA) certificates and configuration: NDES has its own certificate-based identity separate from the CA it talks to, losing this means SCEP-based enrollment for mobile and non-domain devices can’t be restored even if the underlying CA comes back cleanly.
CES and CEP web enrollment service configuration, including IIS site bindings, application pool identities, and authentication settings, none of which are covered by a CA-level backup.
RADIUS/NPS integration configuration, for 802.1X and VPN authentication scenarios that depend on certificate validation against your CA hierarchy.
Autoenrollment Group Policy objects, which control how domain-joined devices and users automatically request and renew certificates, and which reference specific CAs and templates that need to remain valid post-recovery.
Custom enrollment tooling configuration and credentials, any internally built integration that requests certificates on behalf of users or devices has its own configuration and service account credentials that won’t be reconstructed from a CA restore alone.

Publication and Trust Infrastructure Artifacts

CDP and AIA content at every publication location, file shares, HTTP endpoint content, and historical CRLs, needed both to restore ongoing publication and to keep validating certificates issued before the incident.
DNS records for any abstracted publication hostnames, if your CDP/AIA infrastructure publishes under a CNAME or load-balanced virtual name rather than a literal server name, that DNS configuration is itself a recovery artifact, and losing track of it undermines the entire point of using an abstracted hostname.
Load balancer or reverse proxy configuration, if your publication infrastructure sits behind one, documented explicitly rather than assumed to be reconstructable from memory.
A record of every certificate and CRL currently in circulation from each CA, or at minimum, the ability to reconstruct that record, since relying parties validating older, still-valid certificates need continued access to the specific CDP/AIA content those certificates reference.

Documentation and Governance Artifacts

Your Certificate Policy and Certification Practices Statement (CP/CPS), the governing document your entire PKI operates under, and a required reference point for how recovery itself should be conducted and evidenced.
Ceremony scripts and logs for every key generation and renewal event, across the full hierarchy, not just the root, these are both operational reference material and compliance evidence.
Defined recovery time and recovery point objectives, specific enough to actually test against, “restore quickly” isn’t a target you can validate a plan against, a specific RTO and RPO is.
A current contact and escalation list, covering who executes recovery, who holds access to backup and key material, and who needs to be notified, documented rather than assumed to be institutional knowledge.
The last-tested date and outcome for the DR plan as a whole, not just for individual backup components, a plan that’s never been exercised end to end is unverified regardless of how complete the underlying artifact inventory looks on paper.

Building the Inventory Into a Tested DR Plan

Catalog every artifact with an owner, a storage location, and a last-verified date: a spreadsheet or formal DR management tool works, what matters is that every item above has a named owner and a date someone actually confirmed it’s current and accessible.
Sequence your recovery plan explicitly, root before intermediates before issuing CAs, before dependent services: document the order recovery has to happen in, not just the list of what needs recovering, since restoring a dependent service before its parent CA is available accomplishes nothing.
If you operate hot or cold standby DR infrastructure, keep it synchronized deliberately, standby issuing CAs that exist but haven’t been regularly tested and kept configuration-current provide false confidence rather than real resilience.
Run a genuine test restore on a defined schedule, at minimum annually and after any material change to your hierarchy, templates, or dependent services, and treat a failed test as the valuable finding it is rather than something to quietly fix and forget to document.

How Encryption Consulting Can Help

Building a complete ADCS disaster recovery inventory across a real hierarchy, with root and multiple issuing CAs, HSM-backed keys, and a full stack of dependent services, is exactly the kind of cross-cutting work that benefits from an outside review, since it’s easy to be confident about the pieces you touch regularly and blind to the ones you don’t.

Encryption Consulting’s PKI Services team supports this directly:

DR artifact inventory and gap assessment: working through every category in this guide against your actual hierarchy to identify what’s genuinely covered, what’s assumed, and what’s missing entirely.
Recovery sequencing and runbook development: documenting the correct order of operations across root, intermediates, issuing CAs, and dependent services, so recovery isn’t improvised during an actual incident.
HSM and key ceremony recovery validation: confirming your key recovery process for both root and issuing CAs is documented, tested, and satisfies your compliance framework’s evidentiary requirements.
DR testing and validation, running or facilitating an actual test restore against your documented plan, so you have a real, current answer to whether your DR capability works, not just whether your inventory looks complete.
Ongoing DR governance, keeping your inventory, RTO/RPO targets, and test schedule current as your PKI hierarchy and dependent services evolve.

If you’re not confident your current ADCS disaster recovery plan actually covers everything needed to restore full certificate-based operations, our PKI Services team can assess your inventory and help you build and test a real recovery capability.

Conclusion

A complete ADCS disaster recovery plan is broader than any single CA’s backup, it’s an inventory of every artifact needed to rebuild root and issuing CAs together, restore the templates and AD objects they depend on, and bring every dependent service, from NDES to autoenrollment, back to a working state. Build the inventory category by category, assign ownership and verification dates to every item, sequence the recovery order explicitly, and test the whole thing on a real schedule. An inventory that’s never been tested is a list of assumptions with a professional-looking format, not disaster recovery.

Not confident your ADCS disaster recovery plan covers everything needed to rebuild your hierarchy? Talk to our PKI Services team about assessing your DR artifact inventory. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What’s the difference between backing up a CA and having an ADCS disaster recovery plan? Backing up a CA covers one server’s database, key, and configuration. A disaster recovery plan covers your entire hierarchy, root and every issuing CA, plus every dependent service, publication point, and piece of governance documentation needed to restore full certificate-based operations, not just bring one server back online.

Does an ADCS DR plan need to include the offline root CA? Yes. The root CA is the least frequently touched part of your hierarchy but the most consequential to lose, since every issuing CA and every certificate in your environment ultimately depends on it. Root CA recovery artifacts, including HSM-backed key recovery and ceremony documentation, belong in your DR inventory even though the root itself is rarely online.

Are certificate templates part of ADCS disaster recovery, or is that an Active Directory concern? Both. Certificate templates are Active Directory objects and technically fall under AD backup and recovery, but a complete ADCS DR plan still needs to explicitly account for them, since a recovered CA with no templates, or with a mismatched issuance list, can’t actually issue certificates.

What service dependencies are most commonly missing from ADCS DR plans? NDES’s registration authority certificates and configuration, CES/CEP web enrollment settings, and any custom enrollment tooling’s credentials and configuration are the most frequently missing pieces, since none of these are captured by a CA-level backup and each requires its own explicit recovery artifact.

How often should an ADCS disaster recovery inventory be tested? At a minimum, annually, and after any material change to your CA hierarchy, templates, or dependent services. An inventory that hasn’t been tested against an actual restore is a list of assumptions, not a validated recovery capability.