Disaster Recovery for Managed PKI and PKIaaS: Questions Every CISO Should Ask

Every PKIaaS vendor markets redundancy. “Highly available,” “fully redundant infrastructure,” “robust data backup,” and “exceptional disaster recovery” appear in product descriptions across the managed PKI market. These phrases are marketing commitments, not engineering specifications. When a CISO evaluates a PKIaaS provider’s disaster recovery capabilities, the right question is not whether they have a DR program. The right question is what happens to the organization’s certificate infrastructure when specific failure scenarios occur, what the provider is contractually committed to in those scenarios, and how recently the provider has tested its recovery procedures under actual conditions.

PKI failure is not like most infrastructure failures. If a web server goes down, users get a 503 error until the server is restored. If the OCSP responder for a PKIaaS deployment goes down in an environment with hard-fail OCSP checking, every device that tries to authenticate over 802.1X fails to connect to the network. Every VPN client with certificate-based auth fails to connect. Every smart card logon attempt to a domain controller fails. The blast radius of PKI unavailability is proportional to how deeply certificate-based authentication is embedded in the environment, and for organizations that have done that embedding correctly, it is very large.

This post is a structured evaluation guide for CISOs and their teams assessing a PKIaaS provider’s DR capabilities. It covers the questions to ask, what a strong answer looks like, and what answer patterns should prompt deeper scrutiny. The questions are organized by the component or scenario they address.

Quick Answer: What Are the Core PKIaaS DR Evaluation Areas?

The seven evaluation areas for PKIaaS disaster recovery are: CA private key backup and recovery; HSM failure and backup HSM activation; CRL and OCSP availability under failure conditions; geographic failover for certificate issuance; recovery testing frequency and evidence; M-of-N quorum control under disaster conditions; and provider incident communication and notification obligations. Each area has specific questions that a PKIaaS provider should be able to answer with specificity, not with marketing language. The SLA and the SOC 2 Type II report are the two documents where these answers should ultimately be reflected in writing.

Why PKI Disaster Recovery Is Different from Other Infrastructure DR

Three properties of PKI infrastructure make its DR requirements distinct from most other infrastructure components.

The CA private key is non-recoverable without a backup. If a database goes down, the data can be restored from backup. If a web server is destroyed, the application can be redeployed from its image. If an HSM holding a CA private key is destroyed and there is no key backup, the CA key is permanently gone. A new root CA must be created (with a new key ceremony), a new hierarchy must be built, and the new root CA certificate must be distributed to every trust store that trusted the old one. This is a multi-month recovery program, not a weekend project. The CA key backup is therefore not optional; it is the most important DR component in the entire PKI.

CRL and OCSP unavailability has immediate operational impact. Certificate validity checking is performed at the moment of use: when a TLS handshake completes, when a user authenticates with a smart card, when a device connects to an 802.1X-protected network, when a VPN client connects. If the CRL distribution point or OCSP responder is unreachable at that moment, hard-fail implementations deny the access attempt immediately. Unlike most infrastructure that degrades gracefully under partial failure, a PKI revocation infrastructure failure can produce a binary outcome: all certificate-based authentication works or none of it does.

Recovery dependencies can create quorum problems. Root CA operations require M-of-N custodian quorum. If the failure scenario that triggered DR also affects multiple custodians (a regional disaster affecting a city where several custodians are based), recovery operations that require root CA key access may be blocked until the quorum can be reassembled. This is a DR dependency that most organizations do not account for until they need to perform an emergency root CA operation and discover that three of their five custodians are unavailable.

Category 1: CA Private Key Backup and Recovery

These questions address the backup of the CA private key material, which is the non-negotiable foundation of any PKI DR program.

Question 1: Where is the CA private key backed up, and is the backup in a physically separate location from the primary HSM?

A strong answer specifies the type of backup (encrypted key export under M-of-N controls, or HSM cloning to a backup HSM of the same model), the physical location of the backup (a different data center, ideally in a different seismic zone or geographic region), and the access controls protecting the backup. A vague answer (“we have a secure backup process”) does not confirm that the backup is in a location that would survive the primary site’s failure.

Question 2: Has the CA key backup been restored and tested within the last 12 months?

An untested backup is an assumption, not a verified capability. A strong answer specifies when the last backup restoration test was conducted, whether the test confirmed that the CA could sign certificates using the recovered key material, and where the test result is documented (typically in the SOC 2 Type II report or a dedicated DR test report). A provider who cannot confirm that the backup has been tested should be pressed for a commitment to test it and provide evidence of the test result.

Question 3: What is the Recovery Time Objective for CA key recovery from backup?

The RTO for CA key recovery is the time from the point of HSM failure detection to the point at which a functional CA is operational using the backup key. This involves detecting the failure, retrieving the backup from the secure storage location, activating the backup HSM or decrypting the backup key material, loading the key into the replacement HSM, and verifying that the CA can sign certificates. A strong answer is a specific time commitment (for example, “4-hour RTO for CA key failover, reflected in the SLA”). A vague answer (“we can recover quickly”) is not an SLA commitment.

Question 4: For customer-hosted or hybrid deployments, what support does the provider supply for the customer’s CA key backup and recovery procedures?

In customer-hosted deployments, the customer is responsible for their own CA key backup. The question is what the provider supplies: backup HSM procurement assistance, backup key export procedures documented in the customer’s CPS template, or a dedicated backup and recovery runbook. A provider who sells customer-hosted PKIaaS but supplies no guidance or tooling for the customer’s backup procedures is leaving a significant DR gap that the customer must independently design and test.

Category 2: HSM Failure and Backup Activation

Question 5: What is the failure detection mechanism for the production HSM?

Automated monitoring of HSM health (connectivity, response time, operational status) is required for the provider to detect an HSM failure without depending on a customer-reported outage or manual monitoring. A strong answer describes the specific monitoring mechanism (HSM management software health checks, network-level connectivity monitoring, application-layer CA signing test operations), the alerting path (who is paged on HSM failure detection, within what time window), and the documented escalation procedure.

Question 6: Is there a hot standby HSM, or does recovery require activating a cold backup?

Hot standby means a second HSM is already active, synchronized with the primary, and can take over without human intervention. Cold backup means a secondary HSM exists but must be retrieved from storage, loaded with the backup key, and manually brought online when a failure occurs. The RTO difference between these two approaches can be hours versus seconds. The answer determines the realistic RTO for issuance availability after an HSM failure, which must be consistent with the SLA’s availability commitment.

Question 7: How long does it take to activate the backup HSM and restore full certificate issuance capability?

This is the specific time commitment that must appear in the SLA for HSM-level failures. It should be distinguished from the time to restore CRL/OCSP availability (which may be shorter, since these services do not require the CA private key for pre-signed CRLs) and the time to restore root CA signing capability (which requires M-of-N quorum and may be longer).

Category 3: CRL and OCSP Continuity

CRL and OCSP availability is the PKI DR component with the most immediate end-user impact because its failure is felt at the moment of every certificate validation attempt.

Question 8: How many geographically distributed OCSP responder instances serve the production PKI?

A single OCSP responder is a single point of failure. A strong PKIaaS deployment runs multiple OCSP responder instances in at least two geographically separated availability zones or regions, behind a load balancer or anycast routing that automatically distributes queries and routes around failed instances. A provider who runs a single OCSP responder or does not know how many instances serve the deployment is not operating OCSP infrastructure at enterprise resilience standards.

Question 9: What is the OCSP responder’s guaranteed availability SLA, and what is the consequence if that SLA is breached?

OCSP availability is the commitment that should be most carefully scrutinized because it directly affects authentication availability. A strong answer is a specific percentage (for example, 99.9% monthly, which allows 43.8 minutes of downtime per month) with a defined measurement methodology (what counts as an OCSP failure, how it is measured, and from which monitoring locations) and a defined remedy (service credits, incident report, or other contractual consequence for breach). An OCSP SLA that does not specify the measurement methodology cannot be verified.

Question 10: How long are CRLs valid, and what happens to CRL validation if the CRL publication infrastructure is unavailable for longer than the current CRL’s validity period?

CRLs have a built-in validity period (the nextUpdate field in the CRL). If the CRL publication infrastructure is unavailable for a period exceeding the CRL’s validity period, the CRL is stale and most hard-fail implementations will reject it as if revocation cannot be checked. The answer to this question reveals whether the CRL validity periods are sized appropriately relative to the expected maximum recovery time for the CRL publication infrastructure. A CRL with a 24-hour validity period and a DR recovery time of 6 hours has adequate margin; a CRL with a 24-hour validity period and a DR recovery time of 48 hours does not.

Question 11: Does the provider support OCSP stapling for deployed certificates, and is it enabled by default?

OCSP stapling reduces the real-time dependency on the OCSP responder by caching a recent OCSP response at the server and delivering it to clients as part of the TLS handshake, without requiring the client to make a separate OCSP request. For environments where OCSP responder availability is a concern, stapling with a reasonable staple refresh interval (significantly shorter than the OCSP responder’s Maximum Claim Period) provides resilience against short OCSP outages. The answer reveals whether the provider’s PKIaaS deployment architecture considers OCSP availability as a DR design factor.

Category 4: Geographic Failover for Certificate Issuance

Question 12: In which geographic regions does the provider operate CA issuance infrastructure, and how are requests routed across regions under normal and failure conditions?

A strong answer names specific regions (not just “multiple regions”) and describes the traffic routing mechanism: whether requests are load-balanced across regions under normal operation (active-active) or whether one region is primary and another activates only on failure (active-passive). Active-active across regions provides better resilience and lower latency than active-passive, but both are acceptable if the failover mechanism is automated and the failover time is consistent with the SLA.

Question 13: Does the provider’s ACME, REST API, and other enrollment endpoints have multi-region availability, or is only the OCSP/CRL infrastructure distributed?

OCSP and CRL distribution are read-only operations that can be served from cached data; they do not require access to the CA private key. Certificate issuance requires the CA private key for signing. A provider may have distributed OCSP/CRL infrastructure while running CA issuance from a single region. If the single-region issuance infrastructure fails, OCSP and CRL remain available but new certificates cannot be issued. For environments with automated renewal (cert-manager at 47-day CA/B Forum cadence, SPIRE with 1-hour SVIDs), issuance unavailability causes failures within hours. Confirm whether issuance itself is multi-region or only validation infrastructure.

Question 14: For customer-hosted deployments, what geographic redundancy architecture does the provider recommend and support?

In customer-hosted deployments, geographic redundancy for the issuing CAs is the customer’s responsibility. The provider should supply a reference architecture for HA/DR deployment of the CA software in the customer’s environment, including requirements for HSM clustering or secondary HSM activation, database replication for the certificate database, and network-level health checking for the enrollment endpoints. A provider who sells customer-hosted PKIaaS without a published reference HA architecture is leaving significant design work to the customer.

Category 5: Recovery Testing Frequency and Evidence

Recovery testing questions separate providers with functioning DR programs from providers with DR documentation.

Question 15: How frequently does the provider conduct DR failover tests, and is the test result reflected in the SOC 2 Type II report?

An annual full DR failover test (not a tabletop simulation) is the minimum acceptable frequency for enterprise PKIaaS. A strong answer specifies the test frequency, what constitutes a passing test (production load carried by DR infrastructure for how long, what verifications were performed), and whether the test methodology and results are described in the SOC 2 Type II report’s control testing section. A provider who conducts DR tests but cannot produce documentation of test results is making an unverifiable claim.

Question 16: Can the provider supply the most recent DR test report or the DR-related controls section of their SOC 2 Type II report?

The SOC 2 Type II report is the primary audited evidence of a PKIaaS provider’s operational controls. DR testing should be covered in the report’s description of the provider’s change management, backup, and availability controls. A provider who refuses to share the SOC 2 Type II report under an NDA during a vendor evaluation is not meeting standard enterprise vendor due diligence expectations. The absence of a SOC 2 Type II report entirely should be treated as a significant risk factor for any enterprise PKIaaS procurement.

Question 17: What is the process if a DR test reveals a failure in the backup or failover mechanisms?

This question reveals maturity of the DR program. A strong answer describes the remediation process (incident creation, root cause analysis, corrective action within a defined timeline, re-test before the next production DR test is marked complete), the escalation path if remediation cannot be completed within the defined timeline, and whether customers are notified of material DR test failures. A provider who has never encountered a DR test failure (and has been operating for several years) may not be testing thoroughly enough to surface real failures.

Category 6: M-of-N Quorum Control Under Disaster Conditions

Question 18: What is the M-of-N configuration for root CA operations, and where are the key custodians geographically located?

For vendor-hosted PKIaaS, the provider’s custodians hold the root CA key shares. A strong answer specifies the M and N values, confirms that custodians are distributed across at least two geographic regions (to prevent a regional disaster from disabling the quorum), and describes the secure communication mechanism custodians use to authorize root CA operations from different locations. If all custodians are in the same building or campus, a single physical event can prevent any root CA operations until the quorum is reconstituted.

For customer-hosted or hybrid deployments, the customer holds some or all custodian credentials. The CISO should confirm that the organization’s own custodian distribution satisfies the same geographic diversity requirement, and that the emergency custodian contact procedure is documented and tested at least annually.

Question 19: What is the procedure if fewer than M custodians are available during a disaster recovery event that requires root CA operations?

This is the question most organizations never ask until they need the answer. A strong answer describes: the specific procedure for reconstituting a custodian quorum when some custodians are unavailable (which may involve initializing new custodians using the existing M-of-N quorum, or using an emergency recovery procedure documented in the CPS), the maximum time this reconstitution takes, and whether the procedure has been tested. An honest answer from a provider with a mature DR program might acknowledge that root CA operations requiring quorum can take 24 to 72 hours in a worst-case custodian availability scenario. This is acceptable if it is disclosed and planned around; it is unacceptable if it is discovered during an incident.

Category 7: Incident Communication and Notification Obligations

Question 20: What is the provider’s contractual obligation to notify customers of PKI infrastructure incidents, and what is the maximum notification time?

A strong answer is a specific time commitment in the SLA: for example, “Customers will be notified of P1 PKI infrastructure incidents within 30 minutes of detection through email and status page update, with hourly updates until resolution.” A vague answer (“we will notify you promptly”) is not a contractual commitment. For organizations with their own incident response and communications obligations (DORA Article 17-23, NIS2 Article 23, GDPR Article 33), the provider’s notification timeline directly affects the customer’s ability to meet their own notification obligations. If the provider takes 4 hours to notify the customer of a PKI outage, and the customer’s regulatory obligation is to report a significant ICT incident within 4 hours of detection, the provider’s notification latency is a compliance risk.

What a strong incident communication framework looks like: The provider should operate a public status page (with historical incident data, not just current status) that customers can subscribe to for automated notifications. A dedicated PKIaaS status page separate from the provider’s general website conveys that PKI availability is tracked as a distinct service. The provider should have a defined incident severity classification (P1 for complete issuance or OCSP unavailability, P2 for degraded performance, P3 for non-critical infrastructure events), with different notification timelines and response SLAs for each severity level. Post-incident root cause analysis reports for P1 and P2 incidents should be available to affected customers within a defined window (typically 5 to 10 business days after resolution).

Validating SLA Commitments Against Reality

The questions above are intended to surface specific answers. Once specific answers are obtained, they must be validated against three evidence sources.

The SLA document: Every commitment made verbally during a sales evaluation should be reflected in the SLA. If the sales team claims 99.95% OCSP availability and the SLA says 99.5%, the SLA governs. Read the SLA before signing, not after. Pay specific attention to: the definition of availability (is partial degradation counted as unavailability?), the measurement methodology (is availability measured from the provider’s internal monitoring or from external monitoring points that simulate customer access?), the exclusions (planned maintenance windows, “force majeure” events that are defined broadly, customer-caused outages that the provider attributes to the customer for SLA credit purposes), and the remedy (service credits may be inadequate for the business impact of a PKI outage that prevents authentication across the enterprise).

The SOC 2 Type II report: The SOC 2 Type II report covers the provider’s controls over the previous 6 to 12 months. DR-relevant controls appear in the availability trust service criteria (TSC CC9.1 for risk mitigation, A1 for availability commitments and system monitoring). Review whether the auditor’s testing of DR controls produced any exceptions, whether the control descriptions match what the sales team described, and whether the control testing period is recent enough to be relevant. A SOC 2 Type II report covering the period two years ago is significantly less useful than one covering the last six months.

The public incident history: Review the provider’s public status page for incidents over the past 12 to 24 months. Look for: frequency of P1 incidents (complete service unavailability), time to resolution for those incidents, quality of incident communications (were updates provided on schedule, was the root cause analysis published), and whether the provider’s stated RTO was actually achieved during real incidents. A provider whose status page shows multiple multi-hour P1 incidents with poor communication in the past year has a revealed track record that is more informative than any SLA commitment.

Customer-Side DR Responsibilities

PKIaaS DR is not exclusively the provider’s responsibility. For several failure scenarios, the customer’s response determines the outcome.

Trust store distribution for new root CAs: If the PKIaaS root CA must be replaced (in a scenario where the root CA key is compromised or the root CA certificate expires), distributing the new root CA certificate to every trust store in the environment is the customer’s responsibility. This includes OS trust stores (via Windows GPO, macOS MDM profile, Android MDM policy, Linux ca-certificates), browser trust stores (for organizations that manage browser trust policies), application trust stores (for applications that maintain their own trust store independent of the OS), and network device trust stores. The time required for this distribution is the customer-side DR bottleneck that most organizations underestimate.

CLM monitoring for expiry under DR conditions: If certificate issuance is unavailable for an extended period during a DR event, certificates that would normally be renewed during that window expire without replacement. A CLM layer monitoring the certificate estate and flagging certificates approaching expiry during a provider DR event enables the operations team to prioritize which certificates need emergency manual action and which have sufficient remaining validity to wait for the provider’s recovery. Without CLM visibility, the team is flying blind on certificate expiry risk during the DR event.

Encryption Consulting’s CertSecure Manager provides the certificate inventory and expiry monitoring that enables this DR-aware certificate management, with alerting that can be integrated with SIEM and incident management platforms so that certificate expiry risk surfaces automatically during provider DR events.

How Encryption Consulting Can Help

• PKI Assessment Service: Encryption Consulting’s PKI Assessment Service includes vendor DR capability assessment as part of the broader PKI program evaluation. We conduct the structured evaluation described in this post against your current or prospective PKIaaS provider, review the SLA and SOC 2 Type II report for gaps, and produce a documented risk assessment that identifies contractual and operational DR gaps that require remediation before the provider can be relied upon for enterprise PKI operations.
• PKI as a Service: Encryption Consulting’s PKIaaS offering is designed to answer the questions in this guide with specificity: geographically distributed CA issuance infrastructure with defined RTO commitments, multi-region OCSP with 99.9% availability SLA, FIPS 140-3 Level 3 HSM backup in a physically separate location with annual tested recovery, M-of-N custodians distributed across regions, and documented P1 incident notification within 30 minutes of detection. Contact us at Encryption Consulting to review our DR architecture against your requirements.
• CertSecure Manager: For the customer-side DR responsibility, Encryption Consulting’s CertSecure Manager provides continuous certificate inventory and expiry monitoring across the PKIaaS-issued certificate estate, with configurable alerting and SIEM integration that ensures certificate expiry risk is visible during provider DR events.
• PKI Services: For organizations who need to design and test their own customer-side DR procedures (trust store distribution runbooks, CLM-based expiry triage procedures, M-of-N custodian availability planning), Encryption Consulting’s PKI Services provide advisory support through the design, documentation, and tabletop testing of customer-side PKI DR procedures.

Conclusion

PKIaaS vendors promote disaster recovery as a managed benefit. The value of that benefit depends entirely on the specificity of the provider’s commitments and the evidence that those commitments have been tested under real conditions. “Highly available” and “robust disaster recovery” are marketing descriptions, not SLA terms.

The questions in this guide are designed to convert marketing descriptions into engineering specifications: specific RTOs for specific failure scenarios, specific geographic distribution of infrastructure and custodians, specific test frequencies with documented results, and specific notification obligations in the contract. A provider who can answer all of these questions with specificity and document them in the SLA and SOC 2 Type II report is making verifiable commitments. A provider who deflects with marketing language is asking the customer to trust commitments that cannot be audited.

For organizations where PKI is deeply embedded in authentication, device access, and workload identity, the right time to ask these questions is before selecting a provider and before signing the contract. The blast radius of PKI unavailability is too large to accept vague DR commitments.

If your organization is evaluating PKIaaS providers and would benefit from a structured DR capability assessment, or if you want to benchmark your current provider’s DR commitments against this framework, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when material changes in DORA, NIS2, or other frameworks affecting provider incident notification obligations are published.

Frequently Asked Questions

What is the most critical PKI component to protect in a disaster recovery scenario?

The CA private key. Losing it permanently without a backup requires generating a new root CA with a new key ceremony, rebuilding the entire hierarchy, and distributing a new root CA certificate to every trust store in the environment. CRL/OCSP infrastructure loss is disruptive but recoverable. Every PKIaaS DR evaluation must confirm that the CA key backup exists, is in a separate physical location, is protected under M-of-N controls, and has been tested for successful recovery within the past 12 months.

What happens if a PKIaaS provider’s OCSP responder goes down?

Hard-fail OCSP implementations (common in 802.1X NAC, some VPN clients, and government/financial sector environments) reject certificate-based authentications when OCSP cannot be reached, causing immediate authentication failures. Soft-fail implementations (most browser TLS) allow connections to proceed when OCSP is unavailable. For organizations with hard-fail OCSP environments, OCSP responder unavailability can prevent network access, VPN connections, and smart card logon across the enterprise. OCSP responder HA and multi-region distribution must be confirmed with the PKIaaS provider.

How does M-of-N quorum control affect disaster recovery for a PKIaaS deployment?

M-of-N quorum is required to authorize root CA operations including CA hierarchy recovery. If a disaster event affects multiple custodians who are co-located, root CA operations cannot proceed until the quorum can be reassembled. DR planning must ensure custodians are geographically distributed, emergency contact procedures are documented, and backup key material at the DR site can be recovered under quorum without all custodians traveling to the same location.

What is an acceptable Recovery Time Objective for PKIaaS certificate issuance?

The acceptable RTO depends on the environment’s reliance on automated certificate issuance. Environments with continuous automated renewal (Kubernetes cert-manager, SPIRE SVIDs, CI/CD pipeline certs) can experience cascading failures within minutes of issuance unavailability. Environments with occasional manual issuance may tolerate hours. PKIaaS providers should state specific RTO commitments for issuance, OCSP response, and CRL publication separately in the SLA, not as a single generic availability figure.

What should a PKIaaS provider include in their disaster recovery testing program?

Full DR failover tests (not tabletop exercises) at least annually; OCSP and CRL availability validation from DR infrastructure; HSM backup recovery tests confirming the CA can sign using recovered key material; M-of-N quorum recovery tests under simulated custodian unavailability; and customer notification procedure tests. Results should be documented in the SOC 2 Type II report or a dedicated attestation. A provider who claims to conduct DR tests but cannot produce documented results has an unverifiable claim.