How to Back Up Microsoft ADCS Correctly

Microsoft’s own documentation says this plainly, if you dig for it: the standard CA backup captures the database and private key, nothing more. Every organization that’s discovered this the hard way found out during an actual disaster recovery attempt, restoring a database and key onto a rebuilt server and then realizing the registry configuration, CAPolicy.inf, templates, and dependent services are all missing, unrecoverable from the backup they’d been running for years. This is the complete list of what a real ADCS backup needs to cover, and why “we have a backup” and “we can actually recover” are two different claims.

For CA renewal specifically, see our Enterprise Issuing CA Renewal Checklist and How to Renew an Offline Root CA Without Downtime, both of which depend on having a real, tested backup before you touch anything.

TL;DR: Key Takeaways

A standard CA backup only captures the database and private key: Microsoft’s own documentation is explicit about this, if you want the registry configuration and CA settings included too, you need a separate System State backup or explicit registry export, not just the console wizard or certutil -backup.
HSM-backed keys can’t be captured by certutil at all: they’re deliberately non-exportable through Windows tooling, backing them up requires your HSM vendor’s own key backup or cloning mechanism, run and tested separately.
CAPolicy.inf, templates, and IIS/NDES configuration are commonly forgotten entirely: none of them are touched by a database backup, and each lives in a different location with a different backup mechanism.
Templates live in Active Directory, not on the CA: no CA-level backup captures them, and the CA’s own issuance list (which templates this specific CA is configured to issue) is separate, CA-specific state that also needs its own backup step.
Backup and recoverability are not the same claim: a backup means the data exists somewhere. Recoverability means you’ve tested restoring a fully functioning CA from that data and confirmed it actually works, within a timeframe you’d accept during a real incident.

Backup vs. Recoverability: The Distinction That Matters

Microsoft’s documentation on backing up a certification authority contains a specific, easy-to-miss warning: the standard backup procedure, run through the Certification Authority console’s Backup CA wizard or via certutil -backup, captures only the CA database and private key. If you want the CA’s configuration included as well, the guidance points you toward a full System State backup of the server, a materially different and more comprehensive operation.

This gap is the entire reason “we have backups” and “we can recover this CA” aren’t automatically the same statement. A backup is a claim about data existing somewhere. Recoverability is a claim you can only make after you’ve actually restored from that data, end to end, onto a system that didn’t already have the CA’s configuration intact, and confirmed the result is a genuinely functioning CA, not just a database file and a certificate. Every section below exists because it’s a piece of that full picture that a narrow database-and-key backup leaves out.

CA Database and Private Key

Understand what a full backup actually captures: certutil -backup <path> (or the equivalent console wizard operation) captures the CA database, the private key, and optionally the CA certificate itself, this is the core of any CA backup, but it’s the floor, not the ceiling.
Know the narrower alternative and when it’s appropriate: certutil -backupdb captures the database alone, without the private key, useful for frequent incremental backups between full backups but never a substitute for a complete backup on its own.
Password-protect the private key export and treat that password with root-of-trust-level handling: a software-CSP key backup produces a password-protected file, anyone with both the file and the password can effectively impersonate your CA, store and handle the password accordingly.
Verify the backup is actually restorable, not just present: test-restore it in an isolated lab environment periodically, a backup file that exists but fails on restore has given you a false sense of security, which is worse than knowing you have no backup at all.

Private Keys and HSM Considerations

Recognize that HSM-backed keys are a fundamentally different backup problem: HSM-backed private keys are deliberately non-exportable through standard Windows tooling, that’s the entire security premise of using an HSM in the first place, so certutil -backupkey against one typically fails outright.
Use your HSM vendor’s own backup or cloning mechanism, which is a separate procedure entirely from anything certutil can do, and typically involves cloning the key to a backup HSM partition or token rather than exporting it as a portable file.
Document and test the HSM-side restore process independently from your database and configuration restore process, a successful database restore onto new hardware still leaves you without a working CA if the HSM-backed key can’t be made available on that new hardware.
Treat HSM key backup and recovery as a ceremony-grade procedure, with the same witness, documentation, and access control rigor you’d apply to original key generation, this is genuinely sensitive material even in backup form.

Registry

Understand that critical CA configuration lives entirely outside the database: settings under HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\{CA name} control CRL periods, audit filtering, policy module flags, and publication URL templates, none of which are captured by a database or private key backup.
Export the full configuration tree with certutil -getreg > ca_config_export.txt, this gives you a readable, versioned record of the CA’s actual configuration state that you can compare against or restore from.
Pay particular attention to AuditFilter, CRLPeriod, and any EDITF policy module flags, these are exactly the settings that get silently reset to installer defaults if a CA is ever rebuilt without an explicit registry restore, and Microsoft’s own hardening guidance recommends the maximum audit filter value (127) as a baseline worth confirming and preserving.
Back up publication URL templates and any CRLPartitionFlags or DBFlags configuration explicitly, these directly affect whether restored certificates and CRLs resolve correctly for relying parties, silently losing them in a rebuild is a slow-burning problem, not an immediate one.

CAPolicy.inf

Know exactly where it lives, and that nothing else backs it up for you: CAPolicy.inf is a plain text file, typically in the Windows directory, and it’s not touched by certutil -backup, the console backup wizard, or a database backup in any form.
Back it up as an ordinary file, alongside your database and registry backups, this is genuinely one of the most commonly forgotten pieces of a CA backup precisely because nothing in the standard backup workflow prompts you to include it.
Keep versioned copies, especially around any policy change, knowing what your CAPolicy.inf looked like at the time of a specific certificate issuance or renewal can matter for later troubleshooting or audit purposes, not just for disaster recovery.

Templates and Configuration

Remember that certificate templates are Active Directory objects, not CA-local files: no CA-level backup, however thorough, captures them, because they simply don’t live on the CA.
Back up templates from Active Directory directly, using ldifde against the Certificate Templates container in the Configuration partition, or PowerShell-based export, as part of your broader AD backup and recovery strategy, not as a CA-specific task.
Separately capture the CA’s own issuance list with certutil -CATemplates, this is the CA-specific binding of which templates this particular CA is configured to issue against, distinct from the templates themselves and just as easy to lose in a rebuild.
Document template permissions and enrollment agent configurations alongside the templates themselves, since permissions live in AD as well and are just as invisible to a CA-level backup as the templates are.

IIS and NDES

Recognize that web enrollment, CES/CEP, and NDES all run through IIS, entirely outside anything certutil touches: a complete database and registry backup still leaves these roles unrecoverable without their own explicit backup.
Back up your IIS configuration directly, using appcmd or an equivalent configuration export, to capture site bindings, application pool settings, and authentication configuration for any CA-dependent web roles.
Back up NDES’s registration authority (RA) certificates and registry settings specifically, NDES has its own certificate-based identity and configuration separate from the CA it talks to, and losing this means SCEP-based enrollment can’t be restored even if the underlying CA comes back cleanly.
Document application pool identity accounts and their permissions, these are frequently configured with specific, non-obvious rights that are easy to reconstruct incorrectly from memory during a rebuild.

Publication Points

Back up your CDP and AIA publication infrastructure, the file shares, HTTP endpoint content, and AD Configuration container publication, not just because you need them for a restored CA to function, but because relying parties validating certificates issued before an incident still need historical CRLs and certificates to remain available.
Document the exact publication paths and permissions your CA writes to, a restored CA that can’t write to its own historical publication locations, because permissions weren’t restored correctly, produces confusing, delayed validation failures rather than an obvious immediate error.
Confirm your publication URLs are abstracted rather than tied to a literal server name, if they already are, recovery onto a differently named server is far less disruptive to relying parties, if they aren’t, that’s worth fixing independently of your backup strategy.

Documentation

Write an actual, tested restore runbook, not a mental checklist: the exact sequence, database and key restore, registry restore, CAPolicy.inf placement, template and issuance list restoration, IIS/NDES reconfiguration, and publication point verification, documented in the order it actually needs to happen.
Record when the restore process was last tested, and by whom: a runbook that’s never been executed against a real restore attempt is a hypothesis, not a plan, schedule periodic test restores and keep the results on record.
Maintain key custody and ceremony documentation for HSM-backed key backups separately, this is evidence, not just operational reference material, and it needs to satisfy whatever audit or compliance framework your organization operates under.
Define your actual recovery time objective and confirm your tested process meets it, a technically complete restore procedure that takes three days to execute isn’t recoverability if your business can’t tolerate a CA outage that long.
Keep a current contact list and escalation path for who executes this recovery, who has access to backup storage, and who needs to be notified, documented alongside the technical runbook rather than assumed to be common knowledge during an actual incident.

How Encryption Consulting Can Help

Discovering that a years-old backup routine is missing half of what’s actually needed to recover a CA is the kind of finding you want during a planned review, not during an actual outage.

Encryption Consulting’s PKI Services team supports this directly:

Backup completeness audit: reviewing your current CA backup process against every category in this guide, database, keys, registry, CAPolicy.inf, templates, IIS/NDES, and publication points, to identify exactly what’s missing.
HSM backup and recovery validation: coordinating with your HSM vendor’s tooling to confirm your key backup and cloning process actually works, tested independently from your software-side database restore.
Restore runbook development and testing: building a documented, sequenced recovery procedure and running an actual test restore to validate it, rather than leaving your recovery plan as an untested assumption.
Recovery time objective planning: helping you define a realistic RTO for CA recovery and confirming your backup and restore process actually meets it.
Ongoing backup governance, so backup completeness and restore testing become a recurring practice rather than a one-time project that quietly goes stale as your CA configuration evolves.

If you’re not confident your current CA backup would actually produce a working CA if you needed it, our PKI Services team can audit your backup process and help you build and test real recoverability.

Conclusion

A CA backup that only captures the database and private key looks complete right up until the moment you actually need to rebuild from it. CAPolicy.inf, registry configuration, templates, IIS and NDES settings, and publication infrastructure all live outside that narrow scope, and each needs its own explicit backup step. Build your backup process around the full list, not just the part certutil -backup happens to cover, and don’t consider any of it real recoverability until you’ve tested an actual restore and confirmed it produces a genuinely working CA within a timeframe you’d accept.

Not confident your current CA backup would actually get you back to a working state? Talk to our PKI Services team about auditing your backup completeness and testing real recoverability. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Does certutil -backup capture everything needed to restore a CA? No. Microsoft’s own documentation is explicit that the standard CA backup, whether run through the console wizard or certutil -backup, only captures the CA database and private key. It does not capture the registry configuration, CAPolicy.inf, IIS/NDES settings, or anything else needed to actually rebuild a functioning CA.

Can you back up an HSM-backed CA private key with certutil? No. HSM-backed private keys are deliberately non-exportable through Windows tooling, attempting certutil -backupkey against an HSM-backed key typically fails outright. Backing up an HSM-backed key requires your HSM vendor’s own key backup, cloning, or partition migration mechanism instead.

Where does CAPolicy.inf live, and is it included in a standard CA backup? CAPolicy.inf is a plain text file, typically in the Windows directory, that isn’t touched by certutil -backup, the CA console backup wizard, or a database backup. It has to be backed up separately as an ordinary file, and it’s one of the most commonly forgotten pieces of a CA backup because nothing prompts you to include it.

Are certificate templates included when you back up a CA? No. Certificate templates are Active Directory objects, not CA-local data, so no CA-level backup captures them. Back them up separately from Active Directory, and separately capture the CA’s own issuance list with certutil -CATemplates, since that binding between the CA and the templates it issues is CA-specific state that also isn’t covered by a database backup.

What’s the difference between a backup and recoverability for a CA? A backup means the data exists somewhere. Recoverability means you’ve actually confirmed, through a tested restore, that a fully functioning CA can be rebuilt from that data within an acceptable timeframe, including the database, private key, registry configuration, CAPolicy.inf, templates, dependent services, and publication infrastructure together, not just files sitting in a folder that have never been tested.