PKI design

Design reference

Part IV — Design Reference: Windows Enterprise PKI with Active Directory Certificate Services (AD CS) (as of October 2026)

The design baseline for AD CS across Microsoft, CISA/NSA and DISA comes down to five points: build at least a two-tier hierarchy with an offline standalone root; treat every CA and its backups as Tier 0 assets; keep CA keys in an HSM; tightly scope certificate templates (no enrollee-supplied subject for authentication certificates unless a CA manager approves the request); and design certificate-based logon around strong (SID-based) mapping and NTAuth chaining, both of which Microsoft now enforces with no registry bypass. Microsoft supplies the architecture mechanics, CISA/NSA the threat-driven controls, and DISA the binary compliance rules. NIST and NSA set the cryptographic clock: SHA-1 out by 2030, quantum-vulnerable RSA/ECDSA deprecated after 2030 and disallowed after 2035 (still a draft), and CNSA 2.0 for National Security Systems. That clock now meets a real product milestone, because AD CS on Windows Server 2025 gained ML-DSA issuance in May 2026.

TL;DR

• Architecture baseline:
  • Use an offline standalone root CA, plus one or more online enterprise subordinate (issuing) CAs.
  • Add a policy/intermediate tier only when there is a concrete policy, legal or delegation need. Microsoft-published guidance calls the middle tier “often never utilized”.
  • Configure CDP/AIA (HTTP first) before the first certificate is issued.
  • Renew CA certificates at half-life. Avoid delta CRLs on offline roots.
• Security baseline (Microsoft + CISA/NSA + DISA agree):
  • Treat AD CS as Tier 0 and manage it only from Tier 0 PAWs/jump hosts with dedicated CA admin accounts (DISA V-269099, CAT I).
  • Protect CA keys with an HSM, which CISA/NSA list as a control that “should be implemented”.
  • Encrypt CA backups and restrict them to Backup Administrators.
  • Turn on full CA auditing and forward the logs centrally.
  • Remove the “enrollee supplies subject” flag from authentication templates, or require CA certificate manager approval for them. DISA V-269098 (CAT I) makes manual approval mandatory for certain EKUs.
  • Mitigate ESC8 relay with HTTPS + Extended Protection for Authentication and by disabling NTLM (KB5005413).
• Identity and crypto clock:
  • Strong certificate mapping (KB5014754) has been fully enforced since September 9, 2025.
  • NTAuth chaining for Kerberos certificate logon (KB5057784 / CVE-2025-26647) has been enforced with no bypass since October 14, 2025.
  • Use SHA-256 or stronger. NIST’s draft SP 800-131A Rev. 3 would disallow SHA-1 after 2030.
  • Plan new hierarchies for crypto-agility: RSA-3072/4096 or P-384 today, and a parallel ML-DSA hierarchy for testing. NIST IR 8547 (draft) proposes deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035. NSA CNSA 2.0 requires ML-DSA-87 for National Security Systems.

Authoritative design-source overview

Status is as of October 19, 2026. Licence notes: US federal works (NIST, CISA, NSA, DISA) are generally public domain in the US, though third-party content and logos are excluded. Microsoft Learn/Support content falls under Microsoft Terms of Use; Microsoft Learn documentation text is also published on GitHub under CC BY 4.0, but verify per page. CIS Controls/Benchmarks are free for non-commercial use under CC BY-NC-SA 4.0, with commercial use requiring CIS SecureSuite membership. IETF RFCs fall under the IETF Trust Legal Provisions, which allow free reproduction of the full text. CA/Browser Forum documents are freely published under the Forum’s IPR policy. Practitioner papers are copyrighted by their authors. Everything listed is free to access unless noted.

1. CA hierarchy design

Decision at stake: how many trust tiers to build, how many issuing CAs to run, and which constraints to put on subordinate CAs.

Realistic options:

• Single-tier: an online enterprise root that also issues certificates.
• Two- tier: an offline standalone root plus online enterprise issuing CAs.
• Three-tier: root, then offline policy/intermediate CAs, then issuing CAs.
• Cross-certification / bridge: relevant mainly in federal and DoD interoperability contexts.

What the government and vendor guidelines say:

• Microsoft (current Learn): determine “how many CAs you need and in what configuration before you install any CA.” The page frames the first decision as enterprise vs standalone root and approval/revocation handling. It does not prescribe a tier count.
• Microsoft (archived design-guidance table and Test Lab Guides): an online root is “more susceptible to compromise” and cannot be revoked if compromised; an offline enterprise root is “Not recommended”; two-tier has “no unnecessary offline systems”; in three-tier, the middle tier is “often never utilized and is wasted.” The WS2012 TLG builds a standalone offline root plus an enterprise issuing CA as the reference model. Community summaries of Microsoft training describe single-tier as not recommended for production.
• CISA/NSA: do not prescribe a tier count. They treat the AD CS root CA as a Tier 0 computer object and require securing “both root and subordinate CAs” against Golden Certificate theft.
• IETF RFC 5280: supplies the constraint mechanics — basicConstraints pathLenConstraint; nameConstraints; certificate policies / policy constraints — set in AD CS through CAPolicy.inf.
• NIST SP 800-32 (legacy): describes hierarchical vs mesh/bridge trust models (background for the Federal Bridge).

Trade-offs: two-tier keeps the root key off the network and allows revoking a compromised issuing CA, at the cost of an offline-root operating process. Three-tier adds policy separation but another offline system and more CRLs. More issuing CAs add availability and separation but enlarge the Tier 0 footprint.

Conflicts: none among the authorities reviewed. The question is emphasis: Microsoft optimizes for operational simplicity (two-tier); DoD’s own PKI is a much larger multi-tier/bridge model that internal enterprises are not expected to replicate.

2. CA type and role design

Decision at stake: standalone vs enterprise CA; root vs subordinate; online vs offline; domain membership.

Options: Install-AdcsCertificationAuthority -CAType accepts StandaloneRootCA, StandaloneSubordinateCA, EnterpriseRootCA and EnterpriseSubordinateCA.

What the authorities say:

• Microsoft: enterprise CAs integrate with AD DS (publish configuration to AD, use templates, support autoenrollment). Standalone CAs do not use templates; their CRLs and CA certificates “must be manually published into Active Directory.” An offline root should therefore be standalone and non-domain-joined; the archived table rates an offline enterprise root as an uncommon configuration “with no known benefit.”
• CISA/NSA: CAs should do nothing but AD CS — “do not install any non-security-related services or applications” — and should use application control. These favour dedicated servers over co-locating the CA role with domain controllers; Microsoft’s archived table likewise lists “Enterprise root CA on a domain controller” as the weakest option.
• DISA: V-269099 requires AD CS servers to be managed only from Tier 0 PAWs, implying enterprise (domain-joined) issuing CAs sit inside the Tier 0 boundary.

Trade-offs: enterprise CAs bring automation (templates, autoenrollment, SID extension, NTAuth publication) but also AD-wide attack surface (template ACLs, the ESC paths). Standalone CAs reduce AD dependency but need manual approval and publication. CA naming is effectively permanent — renaming the server after install invalidates issued certificates; the CA common name should not be the FQDN or the computer name.

3. Cryptographic design

Decision at stake: key algorithm and size; hash algorithm; provider and key protection; CA key lifetime relative to algorithm strength; FIPS; post-quantum readiness.

Realistic options: RSA-2048/-3072/-4096; ECDSA P-256/P-384 via a CNG KSP; SHA-256/-384/- 512; software KSP, network/PCIe HSM, or TPM-backed keys for end entities; ML-DSA-44/-65/- 87 on WS2025.

What the authorities say:

• Microsoft: choose the provider, hash and key length after checking “what cryptographic options the applications and devices that you intend to use can support.” Legacy CSPs support only SHA-1/MD-family hashes; the Microsoft Software KSP supports SHA-256/384/512 and ECDSA — so new CAs should use a CNG KSP. An HSM must be installed before the CA is configured if CA keys are to live on it. Microsoft’s sample root CAPolicy.inf uses RenewalKeyLength=4096.
• NIST SP 800-57 Pt 1 Rev. 5: suggests “a maximum cryptoperiod of about one to three years” for a private signature key; for certified keys, the cryptoperiod ends at the notAfter of the last certificate issued for that key, and the validity periods of the original and all renewed certificates “shall not extend beyond” the key’s cryptoperiod. NIST calls these “rough order-of-magnitude guidelines.” The 1–3-year figure is far shorter than typical 10–20-year root lifetimes; no NIST document sets a separate CA-key cryptoperiod.
• NIST SP 800-131A: Rev. 2 (final) governs 112-bit minimum security (RSA- 2048/P-224+). The Rev. 3 draft would deprecate SHA-1 and 224-bit hashes “through December 31, 2030” and disallow them thereafter, moving toward 128-bit security. NIST’s 2022 announcement says SHA-1 will be retired for all applications by December 31, 2030.
• NIST IR 8547 (initial public draft, Nov 12, 2024; still draft): proposes deprecating quantum- vulnerable public-key algorithms at 112-bit strength after 2030 and disallowing all quantum- vulnerable public-key algorithms after 2035.
• FIPS 186-5 (current signature standard) and FIPS 204 (ML-DSA, Aug 13, 2024) define approved algorithms; SP 800-208 covers stateful hash-based signatures (LMS/XMSS), suited to firmware signing, not general CA use.
• NSA CNSA 2.0 (National Security Systems): ML-DSA-87 for signatures, ML-KEM-1024, AES-256, SHA-384/512, LMS/XMSS for software/firmware signing. New NSS acquisitions must be CNSA 2.0-compliant from January 1, 2027; most categories must use CNSA 2.0 exclusively by 2033, with all NSS quantum-resistant by 2035. Secondary summaries say ML-DSA-44/-65 are not acceptable for NSS.
• EO 14412 / OMB M-26-15 (June 2026, federal civilian agencies): secondary analyses report EO 14412 requires agencies to migrate their most sensitive systems to PQC for key establishment by December 31, 2030 and to PQC for digital signatures by December 31, 2031, with M-26-15 setting a January 2, 2030 deadline for TLS 1.3; agency migration plans are due within 120 days of M-26-15 (reported as about October 22, 2026). These bind federal agencies, not private enterprises.
• Microsoft PQC: AD CS on Windows Server 2025 supports ML-DSA. Microsoft Learn gives the minimum version as “Windows Server 2025 with the 2026- 05 Security update (KB5087539) or later,” supports all three ML-DSA parameter sets in pure mode, and states existing RSA/ECC CAs cannot be converted: “ML-DSA doesn’t support in-place migration of existing CAs. Build a new CA hierarchy in parallel with your existing hierarchy.” PQC is available only through CNG providers.
• CISA/NSA: “Use a HSM to protect key material for AD CS CAs … the private key for CAs cannot be backed up and exfiltrated.”
• NSA (obsolete TLS guidance) and the DISA Windows Server STIGs govern protocol/algorithm configuration of the hosts; they do not set CA key sizes.

Trade-offs: RSA-4096 roots and RSA-2048/3072 issuing CAs maximize compatibility; P-384 is smaller and CNSA 1.0-aligned, but some legacy devices and smart cards lack ECC support. Larger keys and HSMs add cost and latency. ML-DSA certificates are much larger (per Microsoft Learn, an ML-DSA-87 signature is 4,627 bytes vs 2,420 for ML-DSA-44), clients need Windows 11 24H2/25H2 with the 2025-10 update, and NDES enrollment “isn’t currently available” — so parallel ML-DSA hierarchies are a test/pilot track in 2026, not a replacement.

4. Validity and renewal design

Decision at stake: CA certificate lifetimes; when to renew and whether to re-key; end-entity lifetimes; how CRL periods interact with renewal.

What the authorities say:

• Microsoft: “CAs can’t issue certificates that are valid beyond their own validity period.” “A best practice is to renew the CA certificate when half of its validity period is expired.” CAPolicy.inf controls renewal (RenewalValidityPeriod, RenewalKeyLength); Microsoft’s sample root uses 20 years. An issuing CA’s effective issuance window shrinks as its own certificate approaches expiry; renewal at half-life preserves full- length end-entity issuance.
• NIST SP 800-57: renewing a CA certificate on the same key cannot extend total validity beyond that key’s cryptoperiod — so the design favours re-keying at renewal over indefinite key reuse.
• NIST SP 1800-16: for TLS server certificates, maintain an inventory, monitor continuously, automate renewal; executives should “establish formal TLS server certificate management programs.”
• CA/Browser Forum (context only): Ballot SC- 081v3 caps publicly trusted TLS certificates at 200 days from March 15, 2026, 100 days from March 15, 2027 and 47 days from March 15, 2029. Internal AD CS hierarchies that are not publicly trusted are not bound; browsers enforce the limits only for roots in public trust programs.
• IETF RFC 5280: defines validity semantics; does not set lifetimes.

Trade-offs: long internal lifetimes reduce renewal churn but lengthen exposure if a key is compromised; short lifetimes require autoenrollment, CES/CEP, ACME-style tooling or similar automation. Re-keying at CA renewal creates a new CA certificate and key-index CRLs; clients need both chains during overlap.

5. Revocation and publication design (CDP/AIA)

Decision at stake: CRL only, CRL plus delta CRL, or CRL plus OCSP (Online Responder); HTTP vs LDAP publication and ordering; CRL validity and overlap periods.

What the authorities say:

• Microsoft: configure AIA and CDP extensions “before the CA issues any certificates” — changing a URL affects only newly issued certificates. “Avoid publishing delta CRLs on offline root CAs” (the WS2012 TLG sets CRLDeltaPeriodUnits=0). Publish an HTTP CRL location for external and non-Windows clients. “Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved,” so URL order is a latency/availability decision; common practice lists HTTP before LDAP. Microsoft’s Online Responder implements OCSP and on WS2025 can sign responses with ML-DSA.
• IETF: RFC 5280 defines CRLs, delta CRLs, CDP and AIA; RFC 6960 defines OCSP; RFC 5019 defines a lightweight, cache-friendly OCSP profile.
• CISA/NSA: stress that rogue or attacker-obtained certificates “remain valid until they are revoked”; revocation must be part of incident response.
• No authority reviewed here mandates OCSP for internal enterprise PKI. OCSP is optional, justified mainly where CRL size/latency is a problem or relying parties require it.

Trade-offs: delta CRLs give fresher data but more publication jobs and failure points; OCSP gives low-latency checks but responder availability and signing-certificate management become their own dependency; LDAP CDPs suit domain clients only and can create site- unaware lookups. On an offline root, CRL validity and overlap must outlast the interval between ceremonies (long root CRL periods are standard; issuing-CA CRLs are typically days).

6. Certificate template design

Decision at stake: which template schema versions to use; who can enroll; whether subjects are built from AD or supplied in the request; issuance requirements (manager approval, authorized signatures); EKU/application-policy scope; template lifecycle.

What the authorities say:

• Microsoft: version 2+ templates are editable and support autoenrollment; template permissions (Read, Enroll, Autoenroll) define who can obtain certificates; superseding templates migrate holders (e.g., DC certificates). Archived guidance says to remove unneeded templates from the moment the issuing CA is stood up and to document each template’s issuance requirements and enrollment groups. The TechCommunity hardening blog: “Never allow ‘Enrollee Supplied Subject’ without manager approval.”
• Microsoft (patched flaw): CVE-2024-49019 (EKUwu/ESC15, patched Nov 12, 2024) — on schema-version-1 templates that allow a supplied subject, a requester could inject application policies that override the template EKU. Design lesson (practitioner-sourced): avoid publishing v1 templates; duplicating a v1 template creates a v2+ template.
• CISA/NSA: an ESC1-vulnerable template has four properties — low-privilege enrollment, an authentication EKU, a supplied SAN, no manager approval. Mitigations: remove the Enrollee Supplies Subject flag; restrict write permissions on templates; remove the CA flag EDITF_ATTRIBUTESUBJECTALTNAME2; require CA Certificate Manager approval where a SAN can be supplied; remove authentication EKUs where not needed. Templates enrollable by Domain Computers are a pathway if attackers can create machine accounts.
• DISA V-269098 (CAT I): templates with certain EKUs must require manual CA approval in all cases, including Smart Card Logon and subordinate-CA certificates; templates with authentication-relevant EKUs that allow “Supply in the request” must also require manual approval. Not a finding if “Supply in the request” is not selected and enroll permissions are limited to a select group.
• SpecterOps (practitioner): the ESC1–ESC16 taxonomy. Template-level paths include ESC1/2/3 (supplied subject; any-purpose EKU; enrollment-agent abuse), ESC4 (writable template ACLs), ESC9/10 (weak mapping or no security extension), ESC13 (issuance-policy-to-group links), ESC15 (EKUwu). CA-level paths include ESC6 (SAN flag), ESC7 (CA ACLs), ESC8/11 (relay) and ESC16 (SID security extension disabled CA-wide). Certify 2.0 enumerates ESC1–ESC16.

Trade-offs: manager approval is strong but does not scale for high-volume templates; tight enrollment ACLs plus AD-built subjects scale through autoenrollment but depend on ACL hygiene; unpublishing v1 defaults can break legacy workflows unless duplicates are issued first.

7. Enrollment and endpoint design

Decision at stake: which enrollment interfaces to expose (GPO autoenrollment; CA Web Enrollment; CES/CEP; NDES/SCEP; third-party ACME/EST gateways); whether to require key attestation.

What the authorities say:

• Microsoft: autoenrollment (template permissions plus a GPO) is the native domain path; CES/CEP serve non-domain or off-network clients; NDES implements SCEP for devices; TPM key attestation can be required on v4 templates.
• Microsoft ADV210003 / KB5005413 (ESC8/PetitPotam): Web Enrollment and CES accept NTLM by default and are relay targets. Primary mitigations: “enabling EPA and disabling HTTP on AD CS servers” (enable Extended Protection for Authentication and Require SSL — EPA is ineffective without Require SSL). Further: restrict incoming NTLM on AD CS servers by GPO, disable NTLM in IIS for these role services, and disable NTLM domain-wide where possible.
• CISA/NSA: disable NTLM wherever possible; otherwise enable LDAP channel binding, EPA and SMB signing. Install only the AD CS functions that are needed (remove unused role services such as Web Enrollment).
• IETF: RFC 8894 (SCEP, Informational) documents weak requester authentication (a shared challenge password), so NDES deployments need tightly scoped templates and challenge handling. RFC 8555 (ACME) is the modern automation model behind public-trust renewal; AD CS has no native ACME server.
• SpecterOps: ESC8 (HTTP relay) and ESC11 (RPC relay where the CA does not enforce request encryption) are endpoint-design issues, not template issues.

Trade-offs: each additional enrollment endpoint widens the attack surface and the Tier 0 boundary; NDES enables device enrollment but concentrates a registration-authority credential (avoid where an MDM/connector with better authentication is available); key attestation raises assurance but requires TPM-capable clients and attestation trust configuration.

8. Identity binding and authentication design

Decision at stake: how certificates map to AD accounts; which CAs are trusted for logon; how domain controllers obtain KDC certificates.

What the authorities say:

• KB5014754 (strong mapping): enterprise CAs embed the account SID in a new security extension (OID 1.3.6.1.4.1.311.25.2). DCs moved to Full Enforcement by default in February 2025; the StrongCertificateBindingEnforcement key stopped being honored with the September 9, 2025 update. Weak implicit mappings now fail; alternatives are certificates carrying the SID extension, strong explicit altSecurityIdentities mappings, or (for offline/third-party CAs) adding the SID via a URL-tag SAN. The DoD Cyber Exchange publishes “name-based strong mappings” guidance for DoD PKI certificates.
• KB5057784 / CVE-2025-26647 (NTAuth): audit phase from April 8, 2025; enforced by default July 8, 2025; from October 14, 2025 AllowNtAuthPolicyBypass is no longer supported (“all certificates must be issued by authorities that are a part of NTAuth store”). The risk scenario is a CA trusted in the root store but absent from NTAuth, combined with an SKI on a privileged account. Design rule: publish only the logon-issuing CAs to NTAuth, and treat NTAuth membership as a Tier 0 control.
• CVE-2022-26923 (Certifried): machine-account dNSHostName spoofing yielded DC-impersonating certificates; fixed by the SID extension and mapping changes above.
• CISA/NSA: monitor KDC events 39/40/41 (no strong mapping; certificate predates the account; SID mismatch) and 4768 with PreAuthType 16 (certificate- based TGT). Set MachineAccountQuota to zero.
• Microsoft (Windows Hello for Business): each DC should have a certificate based on the Kerberos Authentication template, used as a baseline for an updated “Domain Controller Authentication (Kerberos)” template, which should supersede Domain Controller and Domain Controller Authentication. Key trust needs a PKI for DC certificates but not client certificates; cloud Kerberos trust is now Microsoft’s recommended WHfB model over key trust.
• DISA: the WS2025 STIG requires DCs to have a PKI server certificate (V-278159); the OS STIGs require DoD root CA certificates in the Trusted Root store (WS2022 V-254442; WS2025 V-278192, now worded “DoW”).
• IETF: RFC 4556 (PKINIT) defines certificate-based Kerberos pre-authentication; DCs need the KDC Authentication EKU for it, and the same DC certificates support LDAPS.

Trade-offs: strong mapping breaks legacy, MDM-issued and third-party smart-card flows that lack the SID (explicit mappings scale poorly); minimizing NTAuth membership reduces risk but requires inventorying every CA used for logon.

9. CA protection, role separation, auditing and key-backup design

Decision at stake: tier placement; physical and offline protection; administrative role separation; audit settings; backup handling of the CA key and database.

What the authorities say:

• CISA/NSA (Golden Certificate): an attacker with CA admin access can extract the CA certificate and private key (built-in backup tools or Mimikatz/SharpDPAPI) and forge authentication certificates for any user. Mitigations: MFA for privileged users; application control; an HSM; limiting CA access to a subset smaller than Domain Admins; restricting access paths to jump servers/SAWs; single-purpose CA servers; encrypting backups and limiting them to Backup Administrators; central log analysis. Detection “is difficult”: event 4876 fires only for full database backups; enable CAPI2 event 70 (private-key export) and watch 1102 (log cleared) and PowerShell 4103/4104.
• DISA V-269099 (CAT I): set aside one or more PAWs for AD CS management. “A dedicated AD CS/CA Admin account that is only usable on tier 0 PAW or the ADCS server must be used to manage the certificate authority and approve requests.”
• Microsoft: Common Criteria role separation (CA Administrator, Certificate Manager, Auditor, Backup Operator), enforced with certutil
• setreg CA\RoleSeparationEnabled 1; separate Certificate Manager and Key Recovery Agent roles where key archival is used; a two-person key-recovery process (archived guidance). The TechCommunity hardening blog urges role separation and using “an offline root and HSMs, if financially feasible.” The legacy “Securing PKI” paper covers physical security and ceremonies for the offline root (its specific text was not re-verified here).
• Microsoft auditing mechanics: enable “Audit Certification Services” (object access); set the CA audit filter to all categories (certutil -setreg CA\AuditFilter 127), yielding the 4870–4900 event range, including 4886/4887 (request/issue), 4898 (template loaded), 4899 (template updated) and 4900 (template security updated).
• NIST SP 800-53 Rev. 5: SC-12 (key establishment and management); SC-17 (PKI certificates issued under an approved policy); IA-5(2) (PKI-based authentication: validate certification paths, enforce access to private keys, map identities).
• CIS Controls v8.1: asset inventory, secure configuration, privileged-account management and audit-log management apply generically. Neither CIS Controls nor the CIS Windows Server Benchmarks contain AD CS-specific design guidance comparable to DISA’s.

Trade-offs: HSMs prevent key export but add cost and need HSM-specific backup/DR; role separation blocks a single administrator from both configuring and approving but can be heavy for small teams; offline roots need disciplined ceremonies and media custody.

10. Logging and monitoring design

Decision at stake: what to collect from CAs and DCs; where to send it; what to alert on.

What the authorities say:

• CISA/NSA: centrally log and analyze, “in a timely manner”: CA events 4886, 4887, 4899, 4900, 4876, 1102 and CAPI2 70; DC events 39, 40, 41, 4768 (PreAuthType 16) and 4674 (template security-descriptor operations). Hunt for Client Authentication certificates whose subject differs from the requester.
• Mandiant (practitioner): detection guidance using events 39, 41 and 4887 to spot SID mismatches and CVE-2022-26923-style abuse.
• DISA: the AD Domain STIG V-269097 requires Kerberos logging on DCs in domains hosting AD CS.
• Microsoft: Enterprise PKI (pkiview.msc) shows chain, AIA and CDP health and expiry for every CA in the forest; Microsoft Defender for Identity’s AD CS sensor surfaces template and CA misconfigurations (cited by CISA/NSA).
• NIST SP 800-53: AU-8 (time stamps) and SC-45 (system time synchronization) underpin cross-source correlation; DISA’s AD Forest STIG requires the forest-root PDC Emulator to take time from an authoritative external source (V- 243504).
• NIST SP 1800-16 and SP 800-57 (Section 9.2.2): maintain certificate inventories with assigned owners and continuous status monitoring.

Recommended alert set (synthesized): template ACL or settings changes (4899/4900/4674); CA backups and private-key exports (4876, CAPI2 70); audit-log clearing (1102); issuance where the SAN or subject does not match the requester; KDC 39/41; changes to NTAuth or CA configuration flags; expiring CA or CRL objects.

Where authorities agree, differ or conflict

Caveats and items that could not be verified

• ML-DSA GA: Microsoft Learn (“What is ML-DSA support in AD CS?”, May 12, 2026) documents the May 2026 KB5087539 requirement and all three parameter sets. The “no in-place migration” point is also Microsoft-documented.
• NIST drafts: IR 8547 (Nov 2024) and SP 800-131A Rev. 3 (Oct 2024) were still initial public drafts as of this review, per NIST CSRC pages relayed by a research subagent. One third-party site claiming a finalized IR 8547 contradicts NIST and was disregarded.
• NIST SP 800-57: the 1–3-year figure is NIST’s general private-signature-key guidance; NIST gives no separate CA-key cryptoperiod, and figures such as “10–20 years” attributed to NIST by third parties are not NIST text.
• DISA versions: AD Forest STIG V3R2 is confirmed; whether a manual V3R3 exists was not resolved. The Windows Server STIG versions (WS2022 V2R10, WS2025 V1R3) come from third-party mirrors, not DISA Cyber Exchange.
• EO 14412 / OMB M-26-15: details come from secondary analyses (Zscaler, PostQuantum.com) rather than the Federal Register text.
• The September 2024 AD guidance was co-authored with non-US agencies; per scope it is treated here only as a CISA/NSA source. The 2026 ASD-hosted revision was not used.
• Microsoft “single-tier not for production”: this wording appears in community summaries and archived Microsoft material; the current Learn design page does not state a tier recommendation.
• The legacy “Securing PKI” white paper, the CAPolicy.inf, Online Responder, NDES and Install-AdcsCertificationAuthority pages, the CIS Controls/Benchmark specifics, the NSA TLS guidance and the IETF RFC details are summarized from established knowledge and were not re-fetched during this review.
• The Microsoft TechCommunity hardening blog is a field-engineer post, not formal product documentation; its page body did not render on fetch, so its points are drawn from search extracts.
• Licensing statements are general. Confirm per-document terms before republishing excerpts.

Annotated source catalog

Reference Collection: Certificate Authority Design and Implementation with Microsoft AD CS (Windows PKI) — Status as of October 2026

The baseline for a Windows enterprise PKI comes from three kinds of source that fit together. Microsoft’s guidance supplies the AD CS–specific design and configuration rules. NIST supplies the cryptographic and key-management rules. CISA/NSA and DISA supply the hardening and detection expectations. The most consistent message across all of them is that AD CS is Tier 0 identity infrastructure. Its CA keys, templates and enrollment endpoints can compromise an entire domain, which is why the 2025 Microsoft enforcement changes (strong certificate mapping and NTAuth chaining) are now mandatory with no registry bypass.

1. TL;DR — summary of the guidance baseline

• Design baseline (Microsoft): use a two-tier hierarchy (offline standalone root plus online enterprise issuing CA) for most organizations; avoid single-tier in production; configure CDP/AIA (HTTP-first) before issuing any certificate; renew the CA certificate at half-life; protect CA keys with an HSM where feasible. Since KB5014754 (registry bypass removed September 9, 2025) and KB5057784 (NTAuth bypass support removed October 14, 2025), certificate-based logon fails unless certificates are strongly mapped and chain to a CA in NTAuth. AD CS on Windows Server 2025 gained ML-DSA issuance in May 2026 (KB5087539).
• Government baseline: NIST SP 800-57 Pt 1 Rev 5 is still the final key- management reference (Rev 6 was in draft from December 2025). SP 800-131A Rev 2 is the algorithm-transition rule in force (the Rev 3 draft would retire SHA-1/SHA-224 after 2030). The draft NIST IR 8547 proposes deprecating RSA/ECDSA at 112-bit strength after 2030 and disallowing quantum-vulnerable algorithms after 2035. CISA/NSA (jointly with Five Eyes partners) treat AD CS compromise and “Golden Certificate” theft as top-17 AD attack techniques. DISA’s AD Forest STIG makes CA certificate-manager approval and Tier 0 PAW management CAT I (high) requirements.
• What is not binding on internal PKI: the CA/Browser Forum Baseline Requirements, including the 200-day maximum for public TLS since March 15, 2026, falling to 47 days in 2029. Internal AD CS CAs set their own policy. The authorities differ most on validity periods, whether OCSP is required (no authority reviewed mandates it for internal PKI), and how fast to drop RSA/SHA-1. Note also that NIST timelines in late 2026 rest partly on drafts.

2. Guidance landscape overview

3. Section A — Microsoft official guidance (by topic)

A1. AD CS role overview and what’s new (Windows Server 2022/2025, PQC)

What is Active Directory Certificate Services? — Microsoft Learn — https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/active-directory- certificate-services-overview — current; free.

• Scope: describes AD CS as a Windows Server role for issuing and managing PKI certificates. Role services covered: Certification Authority (root/subordinate), Web Enrollment, Online Responder, NDES, Certificate Enrollment Policy Web Service (CEP), and Certificate Enrollment Web Service (CES). Also covers TPM key attestation.
• Key points: certificates bind an identity to a private key. Enterprise integration uses Active Directory identity data and Group Policy to control which users and machines get which certificate types. TPM key attestation prevents export to unauthorized devices.

Post-quantum (ML-DSA) in AD CS — Microsoft Security blog on TechCommunity, “New Windows Features to Secure Today’s Data in a Post-Quantum World” (2026) and “Post- Quantum Cryptography APIs Now Generally Available on Microsoft Platforms” (November 2025) — current; free.

• Timeline:
  • ML-KEM and ML-DSA became generally available in the CNG/SymCrypt libraries and certificate functions on Windows 11 (24H2/25H2) and Windows Server 2025 in the November 2025 update.
  • Microsoft states that “ADCS support for issuance of ML-DSA certificates in Windows Server 2025 is now generally available as of May 2026.” Microsoft’s own KB5087539 release notes (May 12, 2026; OS Build 26100.32860) confirm this; the AD CS entry, added May 15, 2026, says the update “adds support for Module-Lattice-Based Digital Signature Algorithm (ML-DSA) post-quantum signatures in Active Directory Certificate Services (AD CS).” The Windows Server release-information table on Microsoft Learn lists the same date, build and KB.
  • Capabilities stated: three parameter sets (ML-DSA-44, -65, -87). Quantum-resistant signing across CAs and OCSP Responders. Microsoft frames this as a way to evaluate PQC issuance and validation workflows.
  • Coming next: composite ML-KEM and composite ML-DSA are in Windows Insider preview and are expected to reach general availability later.
  • Practitioner claims (not Microsoft-verifified here): Practitioner sources (Richard Hicks, Microsoft MVP; Encryption Consulting, a vendor) state that existing CAs cannot be converted in place, so a parallel ML-DSA hierarchy is needed. They also report that late-2025 updates added CRL partitioning and 16K database page support. Treat these as secondary until confirmed in Microsoft’s AD CS “What’s new” documentation.

A2. PKI design considerations (hierarchy, CA types, validity, CDP/AIA)

PKI design considerations using Active Directory Certificate Services — Microsoft Learn (author metadata: Orin Thomas) — https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/pki-design-considerations — ms.date 2023-08-09, metadata updated 2025-06-05; applies to Windows Server 2016/2019/2022/2025; current; free. Verified directly.

• Scope: a high-level planning checklist covering PKI plan, HSM, CAPolicy.inf, cryptographic options, CA name, validity period, CA database, AIA/CDP.
• Key recommendations (paraphrased):
  • Decide the number and configuration of CAs before installing any. For example, decide between an Enterprise and a Standalone root, and how approval and revocation will work.
  • If using an HSM, install and configure it before setting up any CA whose key it will hold. One network HSM can be shared across CAs.
  • CAPolicy.inf is optional. If used, it must be in %systemroot% before install or renewal. The example root CAPolicy.inf sets RenewalKeyLength=4096, a 20-year renewal validity and LoadDefaultTemplates=0.
  • Choose provider, hash and key length for what relying applications support. The page lists built-in CSP/KSP capabilities, including the RSA/ECDSA P- 256/P-384/P-521 software and smart-card KSPs.
  • Do not use the FQDN as the CA common name, and do not make the CA name identical to the computer name. A server cannot be renamed after install without invalidating issued certificates.
  • A CA cannot issue certificates valid beyond its own validity. Best practice is to renew the CA certificate at half its validity period.
  • Consider separate volumes for the CA database and its logs. Locations are set under HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration.
  • Configure AIA and CDP before the CA issues any certificates, because URL changes affect only newly issued certificates.
  • Avoid delta CRLs on offline roots. Publish CRLs at an HTTP location for external and non-Windows clients. Windows clients try URLs in order.
  • Note: this page does not prescribe one-, two- or three-tier designs. That tiering guidance is in the legacy Securing PKI text (A12).

A3. CAPolicy.inf

Prepare the CAPolicy.inf File — Microsoft Learn (Core Network Guide, server certificates) — https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/ server-certs/prepare-the-capolicy-inf-file — current; free.

• Scope: CAPolicy.inf syntax ([Version] required; [PolicyStatementExtension], [CRLDistributionPoint], [AuthorityInformationAccess], [certsrv_server], [Extensions] etc.) and creation steps.
• Key points: the file must exist on the host before the root CA setup routine runs. It must be saved with an .inf extension, not .txt. It controls renewal key length and validity, CRL periods, the CPS/policy OIDs, whether default templates load, and which CDP/AIA entries appear in the root certificate. Microsoft’s examples use fictitious domains; an internal policy OID in an example is illustrative only.

A4. Deployment cmdlets

Install-AdcsCertificationAuthority (ADCSDeployment module) — Microsoft Learn PowerShell reference — https://learn.microsoft.com/en-us/powershell/module/adcsdeployment/install- adcscertificationauthority?view=windowsserver2025-ps — current; free.

• Scope: installs and configures the CA role service after Install-WindowsFeature Adcs-Cert-Authority. Uninstall is via Uninstall-AdcsCertificationAuthority.
• Key points:
  • -CAType selects EnterpriseRootCa, EnterpriseSubordinateCa, StandaloneRootCa or StandaloneSubordinateCa.
  • Parameters cover crypto provider (e.g., RSA#Microsoft Software Key Storage Provider, ECDSA_P256#…), key length, hash algorithm, validity period, parent CA, existing key or certificate reuse, and
  • AllowAdministratorInteraction (used with HSM prompts).

A5. CDP/AIA, CRLs, delta CRLs, overlap, Online Responder

• Current guidance (A2 page): configure AIA/CDP before issuance. Prefer HTTP for broad reach; LDAP is usable for domain clients. Avoid delta CRLs on offline roots.
• Legacy deep guidance: the Windows Server 2012 R2 “Certification Authority Guidance” page (previous-versions, hh831574) covers configuring CDP/AIA after a root install and validating publication with Enterprise PKI (PKIView.msc). Status: legacy.
• Online Responder (OCSP): an AD CS role service that answers certificate status requests (RFC 6960 profile). After the May 2026 update it can sign responses with ML- DSA (A1). Microsoft’s detailed “Online Responder Installation, Configuration, and Troubleshooting Guide” dates from the Windows Server 2008 era and is legacy. It was not re-fetched for this collection.
• CRL overlap and validity settings (CRLPeriod, CRLOverlapPeriod, CRLDeltaPeriod) are set in CAPolicy.inf (A3) or the CA registry. No current Microsoft page reviewed here prescribes specific values; the legacy TLG examples use weekly base CRLs.

A6. NTAuth store and Enterprise PKI view

• NTAuth: the forest-level NTAuthCertificates object lists CAs trusted to issue logon certificates (smart card, PKINIT, and similar) for mapping to AD accounts. Since KB5057784 (A8), DCs require that logon certificates chain to an issuing CA in NTAuth. Enterprise CAs are published to NTAuth automatically at install. Third-party or standalone CAs must be added explicitly (e.g., certutil -dspublish -f <cert> NTAuthCA).
• PKIView.msc (Enterprise PKI): an MMC snap-in showing the health of CA certificates, AIA and CDP locations across the hierarchy. Microsoft documents it as the tool to verify publication (hh831574, legacy).

A7. Certificate templates, least privilege, autoenrollment

• CVE-2024-49019 (MSRC, Nov 12, 2024) is the clearest current Microsoft statement on template hygiene. Certificates from version 1 templates with Source of subject name = “Supplied in the request” are potentially vulnerable unless secured per the “Securing Certificate Templates” section of the legacy Securing PKI text. MSRC’s recommendations:
  • remove unused templates from CAs;
  • restrict enrollment permissions;
  • require certificate manager approval (and/or authorized signatures) for templates that allow enrollee-supplied subjects;
  • monitor what those templates issue.
• Microsoft Core Infrastructure & Security blog, “Secure Configuration and Hardening of AD CS” (Oct 22, 2025) — practitioner-level guidance from Microsoft staff, not formal documentation:
  • never allow “Enrollee Supplied Subject” without manager approval;
  • assign approvers through a role group;
  • use the four CA permissions (Read, Manage CA, Issue and Manage Certificates, Request Certificates) in a role-based way;
  • use an offline root and HSMs “if financially feasible.”
• Autoenrollment: Microsoft’s documented model is template permissions (Read + Enroll + Autoenroll) plus the Group Policy setting Certifificate Services Client – Auto- Enrollment (Computer/User Configuration → Policies → Windows Settings → Security Settings → Public Key Policies). A current Learn page was not re-fetched for this collection.

A8. Domain controller certificates, PKINIT, LDAPS, WHfB, strong mapping, NTAuth chaining

KB5014754 — Certificate-based authentication changes on Windows domain controllers — Microsoft Support — https://support.microsoft.com/en-us/topic/kb5014754- certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8- 4340-a468-4d4f3b188f16 — first published May 10, 2022; latest revision 9/10/2025, which corrected the enforcement date to September 9, 2025; current; free.

• Scope: fixes for CVE-2022- 26923 (“Certifried”), CVE-2022-26931 and CVE-2022-34691. Enterprise CAs embed the requester’s SID in a new certificate extension (OID 1.3.6.1.4.1.311.25.2), and the KDC validates strong mappings.
• Timeline:
  • May 10, 2022: Compatibility mode, which logs KDC events 39/40/41 for weak mappings.
• February 11, 2025: DCs move to Full Enforcement by default unless already configured. Rollback to Compatibility remains possible via StrongCertificateBindingEnforcement.
• September 9, 2025: that registry value is no longer supported. Certificates that cannot be strongly mapped (SID extension or explicit strong altSecurityIdentities mapping) are denied.
• Implication for design: templates used for authentication must be online templates that receive the SID extension, or accounts need explicit strong mappings. This matters especially for offline/SCEP/Intune-issued certificates.

KB5057784 — Protections for CVE-2025-26647 (Kerberos Authentication) — Microsoft Support / MSRC — April 8, 2025; current; free.

• Scope: the KDC now requires that certificates used for Kerberos certificate logon chain to an issuing CA in the NTAuth store. The risk arises when a CA is in the root store but not NTAuth and a Subject Key Identifier mapping exists on a privileged account.
• Phases:
  • April 8, 2025: Audit. Event 45 is logged when a valid certificate doesn’t chain to NTAuth.
  • July 8, 2025: Enforced by default. AllowNtAuthPolicyBypass can revert to audit.
• October 14, 2025: Microsoft support for AllowNtAuthPolicyBypass is discontinued.

DC certificates, LDAPS, PKINIT, Windows Hello for Business (concepts).

• DCs need a certificate with KDC Authentication/Server Authentication EKUs. The current default template for this is Kerberos Authentication, which supersedes the older Domain Controller and Domain Controller Authentication templates.
• The same certificate enables LDAPS on port 636 and PKINIT (RFC 4556) smart card/WHfB certificate-trust and key-trust logon.
• WHfB key trust and cloud Kerberos trust still require DCs to hold valid KDC certificates chaining to NTAuth.
• These template-specifific Learn pages were not re-fetched in this collection; verify against current WHfB deployment docs.

A9. Role separation, auditing, backup, key protection

• Role separation (Common Criteria): AD CS defines CA Administrator (Manage CA), Certificate Manager (Issue and Manage Certificates), Auditor (Manage auditing and security log) and Backup Operator. certutil -setreg CA\ RoleSeparationEnabled 1 plus a service restart enforces one role per user. Users holding two roles are then blocked until a local administrator disables enforcement (certutil -delreg CA\RoleSeparationEnabled).
  • Securing PKI Appendix A flags Event 4897 (“Role separation enabled”) and registry changes to RoleSeparationEnabled as alert-worthy.
• CA auditing: enable the CA audit filter with all seven categories, value 127: certutil -setreg CA\AuditFilter 127. Also enable Audit Certifification Services (Object Access) in advanced audit policy.
  • Securing PKI Appendix A lists the Security-log events: 4885 (audit filter changed, high), 4886 (request received), 4887 (approved and issued), 4888 (denied), 4889 (pending), 4890–4892 (settings), 4896 (rows deleted), 4897 (role separation), 4898 (template loaded), 4899 (template updated), 4900 (template security updated), plus 4876/4877 (backup started/completed).
  • Appendix B explains the audit filter values.
• Backup: back up the CA database and the CA private key/certificate (certutil - backup / Backup-CARoleService), protect backups like the key itself, and audit backup events (4876). CISA/NSA flag backups as the Golden Certificate exfiltration vector.
• Key protection: the legacy Securing PKI text says to use hardware-protected keys and to avoid software keys for CAs unless the PKI is low assurance (lab or proof-of-concept) or an HSM is not operationally or fiscally feasible. It recommends multi-person control and tamper-evident storage of artifacts. The current design page (A2) treats an HSM as optional but requires it to be configured before CA setup. The software KSP keeps the key on the CA’s disk, protected by DPAPI, so a CA administrator or SYSTEM-level attacker can export it. TPM key attestation (A1) applies to subscriber keys, not CA keys.

A10. Web enrollment, CES/CEP, NDES/SCEP — and ESC8

KB5005413 / ADV210003 — Mitigating NTLM Relay Attacks on AD CS (“PetitPotam”) — Microsoft Support and MSRC — released July 23, 2021, revised July 28, 2021; current; free.

• Scope: you are potentially vulnerable if you run Certificate Authority Web Enrollment or Certificate Enrollment Web Service with NTLM.
• Mitigations:
  • enable Extended Protection for Authentication (EPA) and Require SSL on these IIS sites;
  • disable NTLM on AD CS servers (GPO Network security: Restrict NTLM: Incoming NTLM traffific) and/or in IIS for these role services;
  • consider disabling NTLM domain-wide.
  • Related guidance: the legacy Securing PKI text recommends removing role services that are not justified by a business need. CISA amplified the advisory on July 27, 2021.
• NDES/SCEP (RFC 8894): NDES lets non-domain devices enroll via SCEP using a one-time challenge password.
• Securing NDES means a dedicated service account, restricting the NDES templates, HTTPS, and protecting the RA certificates.
• SCEP-issued certificates normally carry requester-supplied subjects. Under KB5014754 they therefore need strong mapping (e.g., SID URL in SAN, or explicit mapping) if used for AD authentication.
• Use NDES only where devices cannot use autoenrollment or CEP/CES.
• The current Learn NDES overview was not re-fetched here.

A11. Monitoring CA events to a SIEM

• Forward CA Security-log events (A9) and KDC System-log events 39/40/41/45 to a SIEM.
• Correlate requester identity against the certificate SAN; Mandiant (practitioner) recommends alerting when they differ.
• Alert on template ACL changes (4899/4900), audit-filter changes (4885) and CA backups (4876).

A12. Legacy “Securing PKI” and the Test Lab Guide (Brian Komar–era)

Securing Public Key Infrastructure (PKI) — Microsoft Learn previous-versions (Windows Server 2012/2012 R2) — https://learn.microsoft.com/en-us/previous-versions/windows/it- pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11) — circa 2014; legacy/archived, but still the deepest Microsoft hardening text. MSRC cited it in Nov 2024 (CVE-2024-49019). Free.

• Chapters: Planning a CA Hierarchy; Physical Controls; PKI Process Security; Technical Controls; Algorithms and Usages; Protecting CA Keys and Critical Artifacts; Monitoring; Compromise Response; Appendices A (events), B (audit filter), C (delegating AD PKI permissions), F (recommendations by impact level).
• Key recommendations:
  • One-tier is “not recommended for any production scenario.”
  • Two-tier is “the recommended design for most PKI solutions.” Three-tier fits policy-CA or high-assurance separation needs.
  • Constrain issuing CAs with path length and EKU constraints.
  • Any CA expiring more than 15 years out should use RSA ≥ 4096 or ECC P-384/P-521. Avoid MD5 and other weak algorithms, and don’t mix algorithms across the hierarchy.
  • Prefer HSMs, with multi-person control.
  • Harden online CAs (firewall, disable LM/NTLMv1, Restricted Admin RDP) and treat them as high-value assets.
  • Require smart cards for PKI administrators.
  • Maintain a CP/CPS and a Policy Authority.
  • Caveat: it predates the ESC research, strong mapping, and Windows Server 2016+ features. Use it as a design and governance text, not a current configuration baseline.

Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy — previous-versions hh831348 — legacy. A step-by-step offline standalone root plus enterprise subordinate walkthrough with fictitious names. Useful only as an illustrative sequence.

A13. Relevant CVEs and advisories (Microsoft)

4. Section B — Government and standards guidance (by publisher)

B1. NIST

SP 800-57 Part 1 Rev 5, Recommendation for Key Management: Part 1 – General — NIST (Barker) — May 2020 — final, current; Rev 6 initial public draft released Dec 5, 2025, comments closed Feb 5, 2026. Free; US Government work, not subject to US copyright.

• Scope: key types, cryptoperiods, security strengths, protection requirements, key-management lifecycle and policy.
• Key points:
  • Defines security strength (112-bit minimum through 2030; RSA-2048 ≈ 112 bits, RSA-3072/P-256 ≈ 128 bits).
  • Gives cryptoperiod guidance, e.g., private signature keys typically 1–3 years. CA keys are long-lived but are bounded by the strength needed over the full validity of issued certificates.
  • Requires protecting keys and metadata, and inventorying keys and certificates.
  • Rev 6 draft changes: adds Ascon (SP 800-232) and FIPS 203/204/205 PQC algorithms and security categories; separates key-establishment keys from key-storage keys; moves algorithm approval timeframes out to SP 800-131A; adds a keying- material storage section.

SP 800-131A Rev 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths — March 2019 — in force. Rev 3 initial public draft — Oct 21, 2024 — draft.

• SHA-1 is already disallowed for digital signature generation and allowed only for legacy verification.
• The Rev 3 draft would deprecate SHA-1, SHA-224, SHA-512/224 and SHA3-224 through 2030 and disallow them after Dec 31, 2030. It would also mark 112-bit RSA/ECDSA “acceptable until 2030.”
• Relevance: AD CS CAs should not sign with SHA-1. The CSP table on Microsoft’s design page still lists SHA-1/MD5 as selectable, which is not an endorsement.

NIST IR 8547 (ipd), Transition to Post-Quantum Cryptography Standards — Nov 12, 2024 — draft.

• Proposes deprecating quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, DH, ECDH) at 112-bit strength after 2030, and disallowing all quantum-vulnerable public-key algorithms after 2035.
• For AD CS this frames ML-DSA hierarchy planning (A1).

FIPS 186-5, Digital Signature Standard — Feb 3, 2023 — final. Approves RSA, ECDSA (including deterministic ECDSA) and EdDSA; curves move to SP 800-186. Per the research summary, DSA is retained only for verifying existing signatures; confirm in the standard. FIPS 204, ML-DSA — Aug 13, 2024 — final. The lattice-based signature scheme that AD CS now issues (A1). SP 800-208, Stateful Hash-Based Signature Schemes (LMS/HSS, XMSS/XMSS^MT) — Oct 29, 2020 — final. Relevant mainly to firmware and code signing, not general CA hierarchies. Its state-management burden makes it unsuitable for AD CS issuing CAs, and AD CS does not offer it.

SP 1800-16, Securing Web Transactions: TLS Server Certificate Management (NCCoE; Vols A–D) — June 16, 2020 — final; free (contains industry-contributed content).

• Scope: an enterprise TLS certificate management program covering inventory, ownership, automation, policy, and private-CA plus public-CA operations.
• Key points: establish a certificate services team; maintain a complete inventory; automate issuance and renewal; protect private keys; plan for CA compromise and algorithm change. It applies directly to AD CS-issued TLS certificates.

SP 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure — Feb 26, 2001 — withdrawn. A conceptual primer only; still cited as a reference in SP 800-53 SC-17.

SP 800-53 Rev 5 — Sept 2020 (updated Dec 10, 2020); online release 5.2.0 (Aug 27, 2025) did not change these controls.

• IA-5(2) Public Key-Based Authentication: enforce authorized access to the private key; map the authenticated identity to the account; validate certificates by building a path to an accepted trust anchor, including status checking; keep a local cache of revocation data for path validation.
• SC-12 Cryptographic Key Establishment and Management: establish and manage keys per defined requirements for generation, distribution, storage, access and destruction.
• SC-17 Public Key Infrastructure Certificates: issue certificates under a defined certificate policy, or obtain them from an approved provider; include only approved trust anchors in managed trust stores.
• Mapping to AD CS: SC-17’s trust- store requirement aligns with controlling NTAuth and enterprise root publication. IA-5(2)’s revocation cache aligns with CRL/OCSP availability design.

B2. CISA / NSA

Detecting and Mitigating Active Directory Compromises — authored by ASD’s ACSC with CISA, NSA, CCCS, NCSC-NZ and NCSC-UK (joint Five Eyes) — Sept 25, 2024 — current. US mirror: https://media.defense.gov/2024/Sep/25/2003553985/-1/-1/0/CTR-DETECTING-AND- MITIGATING-AD-COMPROMISES.PDF. Free; joint international publication, so check the PDF’s licence statement before reuse. Treated here as a CISA/NSA source for its AD CS content.

• AD CS compromise: covers 17 techniques, including AD CS template misconfiguration (ESC1-style enrollee-supplied SAN) and web-enrollment relay. The appendix checklist includes “Remove vulnerable AD CS CA configurations.”
• Golden Certifificate: “a persistence technique that expands upon an AD CS compromise.” An attacker with administrative access to a CA extracts the CA certificate and private key and forges client-authentication certificates for any user. The forged certificates stay valid until the CA certificate expires or is revoked.
• Mitigations (paraphrased): secure both root and subordinate CAs; treat CAs as Tier 0; minimize users with privileged access; don’t use CA servers for anything other than AD CS; implement application control on CAs; centrally log and analyse CA logs promptly.
• Detection: Golden Certificates are hard to detect because CA backup and exfiltration visibility is limited. CA audit logging is not enabled by default. Watch 4876 (backup started), 4886, 4887, 4899, 4900 and 1102 (log cleared) on CAs, and KDC events 39/40/41 on DCs.

CISA alert, “Microsoft Releases Guidance for Mitigating PetitPotam NTLM Relay Attacks” — July 27, 2021 — urges review and application of KB5005413. Free; public domain.

NSA, “Eliminating Obsolete Transport Layer Security (TLS) Protocol Configurations” (CSI U/OO/197443-20) — Jan 5, 2021 — current.

• Use only TLS 1.2/1.3. Remove SSL 2.0/3.0 and TLS 1.0/1.1. Block weak cipher suites and key exchange.
• Relevance: applies to CDP/AIA/OCSP/CES/NDES web endpoints and to the TLS certificates AD CS issues.

NSA, CNSA 2.0 — first released Sept 7, 2022; current PDF May 30, 2025.

• For National Security Systems: ML-DSA-87 for signatures, LMS/XMSS for software and firmware signing, ML-KEM- 1024, AES-256 and SHA-384/512.
• Exclusive-use milestones run through 2030–2033 by category, with all NSS quantum-resistant by 2035.
• NSA sets no separate “PKI deadline.” It is binding only on NSS, but is a useful planning signal for ML-DSA parameter choice.

B3. DISA / DoD

Active Directory Forest STIG — DISA — rules added in V3R1 (Sept 13, 2024); third-party viewers and NIST NCP show V3R2 dated May 15, 2025. Confirm the latest release at public.cyber.mil. Free; public release.

• V-269098 (AD.3145_AD, CAT I/high): “Windows Server hosting Active Directory Certificate Services (AD CS) must enforce Certificate Authority (CA) certificate management approval for certificate requests.” Manual approval is required for templates with authentication-capable EKUs (e.g., Smart Card Logon, Any Purpose, subordinate CA) where the requester can supply the subject. Mapped to CCI-000366 / CM-6.
• V-269099 (CAT I/high): AD CS “must be managed by a PAW tier 0.” A dedicated CA admin account usable only on a Tier 0 PAW or the CA itself must be used to manage the CA and approve requests.

Windows Server STIGs — e.g., Windows Server 2022 STIG V-254413: DC PKI certificates must be issued by the DoD PKI or an approved External Certificate Authority.

DoD PKI context (brief): DoD runs its own PKI under DoDI 8520.02, Public Key Infrastructure and Public Key Enabling (May 18, 2023). PKI-enabling requirements are spread across STIGs (e.g., Application Security and Development STIG). No current standalone “PKI/PKE STIG” for operating a Windows enterprise CA was identified; older PKI documents sit in a “PKI-Sunset” area of the cyber.mil library.

B4. CIS

CIS Controls v8.1 (guide v8.1.2, March 2025) — free with registration; CC BY-NC-ND 4.0.

• 3.10 Encrypt Sensitive Data in Transit (TLS/SSH examples) and 3.11 Encrypt Sensitive Data at Rest are the closest safeguards. 16.11 says to use vetted modules for identity and encryption, and 12.6 covers secure network management protocols.
• No CIS v8.1 safeguard explicitly addresses certificate/PKI or CA management. Certificate-inventory language often attributed to CIS in vendor blogs does not appear in the safeguard text.

CIS Microsoft Windows Server 2022 / 2025 Benchmarks — WS2025 v1.0.0 (Mar 19, 2025) and v2.0.0 (Feb 24, 2026); WS2022 v5.0.0 — free PDF for non-commercial use (CC BY-NC-SA 4.0).

• The Level 1 Member Server profile states it also covers servers running the AD Certificate Services role.
• No AD CS–specific recommendations (templates, CA permissions, audit filter) were identified. CIS applies general OS hardening to CA hosts.

B5. CA/Browser Forum (context only)

Baseline Requirements for publicly-trusted TLS certificates; Ballot SC-081v3 — free. The CA/B Forum Server Certificate Working Group approved the ballot on April 11, 2025. Clint Wilson of Apple proposed it, with Sectigo, Google Chrome and Mozilla endorsing. SSL.com reports “29 votes in favor and none opposed,” and the IPR review ran April 13 to May 13, 2025.

• Maximum public TLS validity: 200 days for certificates issued from Mar 15, 2026; 100 days from Mar 15, 2027; 47 days from Mar 15, 2029. Domain-validation reuse falls to 10 days by 2029.
• Internal PKI is not bound by the BRs. An AD CS CA chaining to a private root is governed by the organization’s own CP/CPS. Browsers enforce BR limits only for publicly trusted roots.

B6. IETF RFCs

B7. Practitioner (non-governmental) research — clearly labeled

SpecterOps, “Certified Pre-Owned: Abusing Active Directory Certificate Services” (Will Schroeder and Lee Christensen) — June 17, 2021 — free.

• Defines ESC1–ESC8, theft (THEFT1–5) and persistence (PERSIST1–3, DPERSIST1–3, including “Golden Certificate” as DPERSIST1), plus PREVENT/DETECT guidance.
• Certify 2.0 (SpecterOps, Aug 11, 2025) covers ESC1–ESC16. Per the Certipy and GhostPack Certify wikis, the later techniques have these sources:
• ESC9/ESC10: Oliver Lyak (Aug 4, 2022).
• ESC11: Sylvain Heiniger.
• ESC12: Hans-Joachim Knobloch.
• ESC13 (Feb 14, 2024) and ESC14 (Feb 28, 2024): Jonas Bülow Knudsen of SpecterOps.
• ESC15 “EKUwu”: Justin Bollinger of TrustedSec (Oct 9, 2024); this is CVE-2024-49019.
• ESC16: Oliver Lyak (May 13, 2025); it covers the CA-wide disabling of the SID security extension.
• Status: a practitioner reference, widely cited by Microsoft blogs and by the CISA/NSA joint guidance’s technique descriptions.

Mandiant / Google Cloud — “Defend Against the Latest Active Directory Certificate Services Threats” (blog) and the hardening white paper “Active Directory Certificate Services: Modern Attack Paths, Mitigations, and Hardening” (2023, aimed at the February 2025 enforcement); “Proactive Preparation and Hardening Against Destructive Attacks: 2026 Edition” (March 2026) — free; some downloads gated.

• Covers ESC1/SAN abuse, relay to web enrollment and Golden Certificate.
• Detection: KDC events 39/41 and CA event 4887; alert when the requester differs from the SAN.

5. Topic crosswalk

Legend: ● explicit guidance; ◐ indirect/general; — no relevant guidance identified.

6. Where authorities agree, differ, or conflict

1. Internal PKI vs CA/B Forum public-trust rules.
   • The CA/B Forum’s 200→100→47-day schedule binds only publicly trusted TLS certificates. No government source reviewed here imposes a maximum validity on internal enterprise certificates.
   • Microsoft’s examples use long CA lifetimes (a 20-year renewal validity in the design-page root example) and leave end-entity lifetimes to template policy.
   • Interpretation: internal PKI teams can legitimately issue longer-lived internal TLS certificates. The direction of travel (NIST SP 1800-16 automation, CA/B Forum), however, favours shorter lifetimes with autoenrollment, and that is the defensible default.
2. SHA-1 and weak algorithm timelines.
   • All sources agree that SHA-1 must not be used for new signatures. NIST disallowed SHA-1 signature generation years ago, and the Rev 3 draft disallows SHA-1/SHA-224 for remaining uses after 2030.
   • Microsoft’s design page still lists SHA-1/MD5 among selectable provider options without a deprecation warning. This is a gap in documentation, not a conflict in policy.
   • RSA-2048 is acceptable under SP 800-131A Rev 2. Under the drafts it becomes “acceptable until 2030” (131A Rev 3) and deprecated after 2030 (IR 8547).
   • Microsoft’s legacy RSA-4096-for-long-lived-CAs rule is consistent with that trajectory. A root CA created in 2026 with a 20-year life will outlast every proposed RSA/ECDSA deadline, which strengthens the case for planning a parallel ML-DSA hierarchy.
3. Is OCSP required?
   • No authority reviewed mandates OCSP for internal PKI.
   • NIST IA-5(2) requires certificate status checking and a local revocation cache, which CRLs satisfy.
   • Microsoft presents the Online Responder as optional, and its own design guidance centres on CDP/CRL configuration.
   • OCSP is an operational choice, useful for large CRLs or non-Windows relying parties.
4. Validity-period guidance.
   • Microsoft says renew the CA at half-life and sets no fixed lifetimes. NIST frames lifetimes through cryptoperiods and the security strength needed for the protected data’s life. The CA/B Forum sets hard maximums for public TLS only.
   • These approaches complement each other rather than conflict, but they do not converge on one number.
5. Manager approval vs automation.
   • DISA V-269098 requires manual certificate-manager approval for authentication-capable templates with requester-supplied subjects. Microsoft (MSRC and the Core Infra blog) recommends manager approval or tight enrollment permissions and authorized signatures.
   • DISA is therefore stricter than Microsoft. Both converge on avoiding enrollee- supplied subjects on authentication templates altogether, which removes the need for manual approval.
6. HSM: required or recommended?
   • Microsoft’s legacy text strongly prefers HSMs except for low-assurance PKI. The current design page treats HSMs as optional. NIST requires key protection commensurate with impact.
   • CISA/NSA’s Golden Certificate guidance implies CA key extraction is the primary risk, without (in the content reviewed) mandating hardware.
   • Interpretation: for any production AD CS that issues authentication certificates, the combined guidance points toward hardware-protected CA keys.

7. Caveats and items that could not be verified

• Microsoft pages not directly verified: current pages for NTAuth, PKIView, template design, autoenrollment, DC certificate templates, LDAPS, WHfB PKI requirements, Online Responder, CES/CEP, NDES, and an AD CS “What’s new in Windows Server 2025” page were not fetched in this research session. Descriptions reflect long-standing

documented Microsoft behaviour and should be checked against the live pages; no URLs are given for them.

• ML-DSA in AD CS: general availability (May 2026) and the three parameter sets are confirmed by Microsoft’s Security blog on TechCommunity. The KB number (KB5087539) and build number come from practitioner sources quoting release notes. The claims about no in-place migration, CRL partitioning and 16K database pages are practitioner/vendor claims.
• KB5014754 dates: Microsoft’s article went through several revisions. A September 2025 revision corrected the final date from September 10 to September 9, 2025; older copies still show September 10.
• NIST drafts: SP 800-57 Pt 1 Rev 6, SP 800-131A Rev 3 and IR 8547 were drafts at last confirmation. Whether any were finalized between early 2026 and October 2026 was not verified. Treat their dates as proposed.
• SP 800-53 IA-5(2) and SC-12 wording is paraphrased from secondary copies and general knowledge, not the official CPRT text. The FIPS 186-5 treatment of DSA is likewise unconfirmed against the standard text.
• CISA/NSA joint guidance: the US-hosted PDF (media.defense.gov) blocked automated retrieval. Content here comes from search extracts of the US and partner-hosted copies. The document is ASD-led; it is used here only as a CISA/NSA co-authored source. Its exact licence statement was not confirmed.
• DISA: the current Active Directory Forest STIG release (V3R2, May 15, 2025, or later) needs confirming at public.cyber.mil; NIST NCP shows an anomalous 2026 “original publication date.” V-269098/V-269099 text was taken from third-party STIG viewers that mirror DISA content. No current standalone DoD PKI/PKE STIG was found.
• CIS: the conclusion that the benchmarks contain no AD CS–specific recommendations rests on profile descriptions and unofficial copies, not a full-text review of the official PDFs. A reported WS2025 v2.1.0 (Sept 2026) is unconfirmed.
• Practitioner sources (SpecterOps, Mandiant, Microsoft staff blogs, MVP blogs) are not authoritative policy. ESC9–ESC16 originate from several researchers, some outside the US.