Microsoft’s AD CS PKI design guidance calls for deliberate decisions about CA hierarchy, request approval, cryptography, names, validity, database, revocation, and Authority Information Access and Certificate Revocation List distribution points. It describes hardware security modules as a way to provide a protected hardware store for CA keys where the design calls for one.
\nMicrosoft’s certificate-template management documentation explains that templates are stored in Active Directory, can be published to enterprise CAs, and include permissions and configuration that control enrollment and certificate purpose. Changes and deletion can affect all enterprise CAs or future issuance, which makes casual cleanup dangerous.
\nCISA’s joint guidance on living-off-the-land techniques identifies AD CS among high-value Microsoft identity infrastructure that should receive appropriate hardening. None of these sources makes one checklist safe for every PKI. Certificate use, application dependencies, offline roots, cryptographic policy, legal requirements, and supported Windows versions vary; qualified PKI expertise is required.
\n\nBegin with a read-only PKI map: every CA and hierarchy relationship, operating system and role service, database and key location, HSM, service account, administrative group, enrollment endpoint, template and publishing CA, CRL and AIA URL, OCSP responder, trust distribution, backup, recovery owner, and dependent application. Protect the inventory because it reveals identity infrastructure.
\nDo not publish a copied template merely because it has a safer-looking name; its effective permissions and fields matter. Do not assume an offline root protects an issuing CA or template with excessive authority. Conversely, do not revoke or remove certificates in bulk without understanding authentication, encryption, signature validation, and recovery impact.
\nThe assessment should produce ranked issuance paths, owners, approved remediation, compensating controls, and retest evidence. AD CS hardening is complete only when the organization can explain who may cause which certificate to be issued, how that action is observed, and how trust and revocation continue through failure and recovery.
\nStop a change if representative clients cannot build the chain, locate revocation information, renew before expiry, or use the certificate for its approved purpose. Preserve the prior template or endpoint only when the rollback is safe and authorized. A security improvement that silently breaks authentication, decryption, or signature validation needs controlled redesign—not an undocumented emergency exception.
\n\n