PKI Operations and Usage

A PKI can be architected perfectly and still fail in production if nobody renews the root CA on schedule, publishes CRLs on time, or has a tested backup to recover from. PKI operations is the discipline that keeps a certificate authority running day to day, distinct from the one-time work of designing and deploying it. Get the operational cadence wrong, and the result is the same regardless of how well the PKI was designed: expired certificates, unreachable revocation lists, and services that stop trusting each other without warning.

Quick Answer: What Are PKI Operations?

PKI operations are the ongoing tasks that deploy, sustain, and expand a Public Key Infrastructure after initial setup: renewing CA certificates, backing up CA data and keys, publishing CRLs, adding or removing CAs and templates, and running periodic PKI health checks. Skipping or delaying these tasks is what turns a well-designed PKI into an outage, since certificates and revocation data expire on a schedule whether or not the organization is tracking it.

Executive Summary

PKI operations cover three categories of recurring work: architectural changes like adding a CA or template, maintenance tasks like CA renewal, backup, and CRL publication, and testing tasks like PKI health checks. Each has its own schedule and consequence for missing it, from an extended outage during CA recovery to services silently accepting certificates they should be rejecting because a CRL never got republished. This post covers the operational tasks organizations need to run, their recommended cadence, the risks of skipping them, and how PKI operations connects to broader certificate lifecycle management and PKI modernization.

Who Should Care About PKI Operations

PKI operations touches identity, security architecture, platform operations, and compliance. Here is what each role should do.

PKI Administrators

Own the operational calendar: CA renewal dates, CRL publication schedules, and backup verification, so no maintenance task slips past its window unnoticed.

Security Architects

Design the CA hierarchy and template structure so architectural changes, adding a CA or template, can happen without disrupting existing certificate issuance.

Platform Teams

Automate what can be automated in the operational task list, particularly certificate discovery and renewal alerts, so maintenance doesn’t depend entirely on someone remembering a date.

Compliance Teams

Confirm PKI health checks and CA backup and recovery testing happen on the recommended cadence, and maintain evidence that CRL publication met its schedule.

CISOs

Treat PKI operations as ongoing infrastructure risk, not a one-time project that ends at deployment, and sponsor the automation needed to keep operational tasks from depending on manual tracking.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 18.5% of affected organizations reported losses exceeding $250,000, with 37.5% of those incidents tied specifically to expired certificates. Missed PKI operations tasks, an unrenewed CA, and an unpublished CRL are exactly the kind of gap that produces outages like these.

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. Shorter certificate lifetimes compress the operational cadence this post describes: a renewal task that used to run every year or two on a private CA hierarchy needs to happen far more often as validity periods shrink industry-wide, making manual tracking increasingly unworkable.

NIST finalized its post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Root and issuing CA renewal, one of the core PKI operations tasks below, is also the natural point to plan a future algorithm migration, since a CA renewed today may need to support post-quantum signatures well before its next scheduled renewal.

Understanding PKI Operations and Associated Risks

PKI Operations refer to the capability of the organization to Deploy, Sustain and Expand PKI services. In other words, it’s the potential of an organization to utilize the PKI services in their environment to keep the services up and running. It comprises all the processes from designing the PKI system to testing it.

There are some risks involved if PKI Operations are not performed:

• ADCS component failures requiring installation of replacement components may not be completed in a timely manner, increasing service outage durations during recovery.
• CA application failures may not be noticed and reported in a timely manner, increasing response and remediation times, leading to increased outage durations.
• Service level agreement failures related to issuing, renewing, or revoking certificates in a timely manner.
• Certificate revocation notification failures leading to services relying on certificate validation failure and acceptance.

PKI Operations Tasks

The following PKI operations tasks are performed at different stages, and periodic execution of the services makes it robust, scalable, secure, and a reduced-risk infrastructure.

Stage	Tasks	Description
Architectural	Adding a new CA Adding a new CA Template Uninstall a CA.	All the changes that are to be done to an existing PKI system.
Maintenance	Renew CAs. CA Backup & Recovery. Publish CRLs on Root CA & Issuing CA.	All the operations that need to be done to keep a check on service (like updation) and therefore get un-interupted services from CA.
Testing	Check for PKI Health.	Check for Certificate status in CDP containers, AIA container, etc.

Below are the tasks that are performed under the PKI operation processes at different stages:

Task	What It Covers	Why / Operational Note	Frequency	Duration
Backup & Recovery of CAs	Database; HSM private key backup; CA Policy File; Configuration Registry Hive; Certificates; Issuing CA template details	Enables DR if CA application fails, DR plan must include taking the CA backup and testing recovery on a different system. Also enables CA migration to a new server and adding an Issuing CA for HA, so a single CA compromise does not bring down the whole system.	As needed	4 hours
CRL & AIA Publication	Publish Root CA CRLs; push updated CRL to environment	Manual publication keeps revocation data current in the environment	Every 6 months (manual)	1 hour
Root CA and Issuing CA Renewal	Root CA: renew keypair. Sub-CA: renew keypair	Root CA issues 10-year certificates to the Issuing CA. Root CA should be renewed at approximately 9 years and 10 months so it retains enough remaining validity to re-sign the Issuing CA certificate for another 10 years. Sub-CA renews every 2 years and 3 months. Actual timing depends on CA certificate validity, which varies by system.	Root CA: every 9 years 10 months. Sub-CA: every 2 years 3 months	Root CA: 1 hour. Sub-CA: 1 hour
Uninstall a CA	Remove AD CS roles and features from the CA Server	Take a full CA backup before uninstalling. When a new CA needs to be added to the PKI system later, the environment can be restored from that backup.	As applicable	1 hour
Add a New CA	Add a CA to the existing PKI system	Required for high availability, load balancing on CA, and assigning different roles intended for that specific CA	As needed	1 hour
Add a Certificate Template	Create and assign certificate templates for specific signing and issuance roles	Example: the Workstation Authentication template is assigned to a CA so it can issue certificates to users and machines connecting to the network for authentication	As applicable	30 min
PKI Health Check	Verify that PKI operations are performing correctly across the system	Run after PKI services are configured, expanded, updated, or maintained to confirm that all PKI operations on the system are performing as expected	After every PKI operation	30 min

All durations are estimates and will vary by organization size and environment complexity.

Recommendation

Architectural PKI Operations – They can be performed as needed or as applicable to the existing PKI requirements.

Maintenance PKI Operations – It is best practice to perform the maintenance task in a timely manner to receive uninterrupted CA Services.

Testing PKI Operations – It should be performed in order to make our PKI services more informed and reliable one.

We recommend that every organization maintain a PKI Operation Guide for detailed and step-by-step PKI operations to get uninterrupted PKI Services.

PKI Operations Glossary

Quick, extractable definitions for the terms used throughout this post.

Term	Definition
PKI Operations	The recurring architectural, maintenance, and testing tasks required to deploy, sustain, and expand a Public Key Infrastructure after initial setup.
Certificate Revocation List (CRL)	A published list of revoked certificates that relying parties check to confirm a certificate is still trusted.
ADCS	Active Directory Certificate Services, Microsoft’s on-premises certificate authority role used to issue and manage certificates.
CA Renewal	The process of generating a new key pair and certificate for a Root or Issuing CA before its current certificate expires.
Certificate Lifecycle Management (CLM)	The process and tooling used to discover, issue, renew, and revoke certificates automatically across an environment.
Crypto Agility	The ability to swap cryptographic algorithms, such as moving to post-quantum algorithms, without redesigning the CA hierarchy.
PKI Health Check	A recurring verification that certificate status, CDP, and AIA containers are functioning correctly across the PKI environment.

PKI Operations Issue Checklist: Impact, Action, and Owner

Issue	Business Impact	Recommended Action	Owner
CA renewal tracked manually or informally	An expired Root or Issuing CA halts all downstream certificate issuance	Put CA renewal dates on a tracked, alerted schedule	PKI administrators
No tested CA backup and recovery process	A CA application failure becomes an extended outage instead of a quick recovery	Back up CA database, keys, policy file, and templates, and test restoration	PKI administrators, platform teams
CRL publication missed or delayed	Relying services may accept revoked certificates as valid	Automate or strictly schedule CRL and AIA publication	Platform teams
No regular PKI health checks	Certificate or CDP/AIA container failures go undetected until something breaks downstream	Run PKI health checks after every operational change and on a recurring schedule	Compliance teams, PKI administrators
No crypto-agility plan tied to CA renewal cycles	Post-quantum algorithm migration becomes a separate, disruptive project instead of part of routine renewal	Evaluate crypto agility at every scheduled CA renewal	Security architects, CISOs

Certificate Lifecycle Management and PKI Modernization

The manual tracking this post describes- renewal dates, CRL schedules, backup verification- is exactly what a PKI modernization program replaces with automation. CertSecure Manager automates certificate discovery, issuance, and renewal so operational tasks like CA and certificate renewal no longer depend on someone remembering a date on a spreadsheet.

Organizations that want the operational burden of running PKI infrastructure without staffing it entirely in-house can rely on PKI-as-a-Service for a managed, cloud-hosted certificate authority. Building a machine identity inventory through CBOM Secure gives operations teams visibility into every certificate that needs tracking, and completing a PQC readiness assessment ensures CA renewal cycles account for the coming post-quantum migration. Encryption Consulting’s PQC Center of Excellence provides guidance on sequencing that work.

For more on why certificate automation matters across the environment, see our Education Center articles on the stages in a certificate’s lifecycle and how to avoid certificate outages.

Measuring Success and Ongoing Audits

Track whether every CA renewal, CRL publication, and backup task is completed within its scheduled window, the number of PKI health checks run after operational changes, and how quickly a CA backup can actually be restored when tested. Audit the operational task calendar, backup restoration test results, and CRL publication logs on a recurring basis, quarterly for policy-driven factors like certificate validity schedules, and continuously for certificate and CA expiry, so a missed maintenance task never turns into an outage.

Frequently Asked Questions

What is the main takeaway from PKI Operations and Usage?

PKI operations are the recurring architectural, maintenance, and testing tasks- renewal, backup, CRL publication, and health checks- that keep a PKI running after initial deployment, and skipping them is what turns a well-designed PKI into an outage.

Why does this matter for enterprise PKI teams?

PKI teams are directly responsible for executing the operational calendar, CA renewal, backup, CRL publication, and PKI health checks that determine whether the infrastructure stays reliable.

What risks increase if this topic is handled manually?

Manually tracked PKI operations increase the risk of missed CA renewals, delayed CRL publication, and untested backups that fail exactly when they’re needed during a recovery.

Which teams should own this change?

PKI administrators own the operational calendar, security architects design the CA hierarchy that operations run against, platform teams automate what can be automated, and compliance teams verify health checks and backup testing happen on schedule.

How does this connect to certificate lifecycle management?

PKI operations tasks like CA and certificate renewal are a subset of the broader certificate lifecycle management discipline; automating certificate lifecycle management is how organizations remove the manual tracking that makes PKI operations risky.

How should organizations measure success?

Track whether every CA renewal, CRL publication, and backup task is completed on schedule, and how quickly a CA backup can actually be restored when tested.

What should be audited or monitored regularly?

Regularly audit the operational task calendar, backup restoration test results, and CRL and AIA publication logs to catch a missed maintenance task before it causes an outage.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Organizations running multiple CAs across on-premises and cloud environments need a single operational calendar covering every CA’s renewal, backup, and CRL schedule, since a gap in tracking any one CA creates the same outage risk as a single-CA environment.

What common mistakes should teams avoid?

Common mistakes include tracking CA renewal dates informally rather than on an alerted schedule, never testing whether a CA backup actually restores, and treating PKI health checks as optional rather than routine after every operational change.

What should be refreshed quarterly?

Review upcoming CA and certificate renewal dates against the current schedule, confirm CRL publication has stayed current, and re-verify the CA backup and recovery process still works as tested.