Book 07 — PKI & Certificates
AD CS to Cloud PKI, Entra CBA and Federal PKI: why certificates outlive every migration, what the target PKI is, who owns the certificate estate, and how to migrate and retire the old CAs
Book 07 — PKI & Certificates: AD CS to Cloud PKI, Entra CBA and Federal PKI
This book replaces the workbook’s PKI Modernization Guide with one ordered book. Every external claim was checked against a primary source on October 20, 2026 and carries a footnote. The guide’s PowerShell assessment module isn’t reproduced here: it stays in the repository’s archive/b07-pki/ folder, with the rest of the original guide, until it has had a technical review. The guide’s old address forwards to this page.
b07-pki-bundle.docx: the whole book as one Word document, regenerated on every site deploy.
15-minute presentation: the Why / What / Who / How deck and its narrated, self-running version are in the repository under presentations/b07-pki/.
Every other migration in this workbook changes which system answers “who is this?” Certificates are how that answer gets proved: domain controllers prove themselves with them, Wi-Fi and VPN trust devices because of them, servers encrypt with them, and PIV cards are them. They also run on their own clock. A certificate issued last year keeps working after the directory it came from is cut over, right up to the day it expires and finds nothing to renew it. That’s why the PKI can’t be retired on the directory’s schedule. The target isn’t one replacement for AD CS but four issuers, each serving the subjects only it can: Microsoft Cloud PKI for Intune-managed devices, a smaller and hardened AD CS for what still depends on Active Directory, the Federal PKI for PIV, and a public CA for names the internet must trust. One lifecycle platform keeps them owned and renewed. For this program that platform is CyberArk Certificate Manager (now part of Palo Alto Networks), because the program already has a CyberArk relationship and doesn’t need a second certificate-lifecycle vendor.
Why, what, who, how
| Question | Chapters | |
|---|---|---|
| Why | Why do certificates outlive every migration? | 01 |
| What | What AD CS holds up today, how to harden what stays, and what the target PKI is | 02, 03, 04 |
| Who | Who decides and who does the work for the certificate estate | 05 |
| How | Issue device and user certificates, run both PKIs through the migration, and keep the estate renewed and checkable until the old CAs retire | 06, 07, 08 |
Appendices: A — Cloud PKI and CBA deployment checklists · B — Certificate template migration matrix
Reading paths
- Executives (20 minutes): Chapters 01, 04 and 05, or the 15-minute presentation.
- Architects: Chapters 01–05, then 07.
- PKI, identity and endpoint engineers: Chapters 02–03 and 06–08, with both appendices at hand.
- Security operations and assessors: Chapters 03, 05 and 08.
Where this book sits in the workbook
This is Book 07 of the Modernization Workbook. Book 02 — Identity & Directory finds the PKI as one of the hidden dependencies on Active Directory. Book 03 — HR-Driven Identity covers PIV issuance and termination. Book 05 — Devices & Endpoints covers the Intune certificate profiles, and Book 06 — Data Platform covers where SQL Server depends on AD CS. For control-level depth on certificates, tokens and cryptographic identity, see the Federal Compliance book Certificates, Tokens and Cryptographic Identity.
Chapters
| Title | Description |
|---|---|
| Chapter 01 — Why Certificates Outlive Every Migration | Why certificates are a naming and trust function that every other migration leans on, why shrinking lifetimes and changing rules make manual lifecycle management fail, and why the move off Active Directory Certificate Services has to be run as its own program. |
| Chapter 02 — What AD CS Holds Up | The typical Active Directory Certificate Services topology and its directory footprint, the certificate template categories and autoenrollment channel, and the inventory and classification framework (MIGRATE, BRIDGE, RETAIN, RETIRE) that maps every use case to its migration path. |
| Chapter 03 — Hardening What Stays | How to harden the AD CS estate that keeps running during the transition: the ESC1–ESC8 misconfiguration classes as a detection and remediation checklist, the program’s risk-scoring matrix, CA auditing, and the hardening baselines for residual AD CS, Cloud PKI and Entra certificate-based authentication. |
| Chapter 04 — The Target PKI: Cloud PKI, AD CS and Federal PKI | The target certificate architecture: what Microsoft Cloud PKI can and can’t issue, its two deployment models and the decision matrix between them, what AD CS is kept for, where Federal PKI fits for PIV, and how CyberArk Certificate Manager covers lifecycle management across issuers. |
| Chapter 05 — Who Owns the Certificate Estate | Who decides, who does the work and who is consulted across the certificate estate: CA administrators, identity, endpoint, server and network teams, application owners, the PIV office, security, the ISSO and AO, and the certificate lifecycle platform owner, with a responsibility matrix, renewal owners per certificate class and the roles each team needs. |
| Chapter 06 — Device and User Certificates: Intune and Entra CBA | How Intune delivers device and user certificates through trusted certificate, SCEP and PKCS profiles, what strong certificate mapping now requires of them, and how Microsoft Entra certificate-based authentication validates, binds and rolls out user certificates. |
| Chapter 07 — Coexistence and Migration | How AD CS and the cloud issuers run side by side during the migration (domain controller and LDAPS certificates, trust in both directions, CRL availability, renewal) and the six-wave migration playbook with entry gates, exit gates and rollback for each wave. |
| Chapter 08 — Lifecycle, Monitoring and Decommissioning | How the certificate estate is kept alive after migration: renewal at scale as public lifetimes shrink, ACME where it applies, CLM inventory and renewal through CyberArk Certificate Manager, revocation and CRL availability, monitoring and drift detection, a troubleshooting reference, the AD CS decommissioning sequence, and the evidence an assessor reads. |
| Appendix A — Cloud PKI and CBA Deployment Checklists | Two working checklists, verified against Microsoft documentation as of October 2026: deploying Microsoft Cloud PKI with Intune, and configuring Microsoft Entra certificate-based authentication through to domain cutover. |
| Appendix B — Certificate Template Migration Matrix | The starting classification for common AD CS certificate templates (MIGRATE, BRIDGE, RETAIN or RETIRE), with the target issuer or Intune profile for each and the dependencies that decide when it can move, verified against Microsoft documentation as of October 2026. |