ASD ISM 2132Central Logging of Certificate Enrolment Requests, Template and AD CS Configuration Changes
Send every certificate enrolment request (successful or failed) and every change to certificate templates or AD CS configuration to a central log so misuse can be spotted and investigated.
Plain language
Microsoft Active Directory Certificate Services (AD CS) issues the certificates that prove who a user, computer or service is. If an attacker can get a certificate issued for someone else, or quietly edit a certificate template or the CA's configuration so that they can, they gain a durable way to impersonate accounts across the network. This control asks for three kinds of event to be captured and sent to a central log rather than left on the CA server: certificate enrolment requests that succeed, enrolment requests that fail, and changes to certificate templates or AD CS configuration. Central logging matters because attackers who compromise a CA can clear its local logs, and because the pattern that reveals abuse (a burst of failed requests, an odd template edit followed by a request against it) is only visible when the events sit together where security staff can search and alert on them.
Framework
ASD Information Security Manual (ISM)
Control effect
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
Server application hardeningTopic
Microsoft Active Directory Certificate Services
Official control statement
Certificate enrolment events, including successful and unsuccessful requests and changes to certificate templates or Microsoft AD CS configurations, are centrally logged.
Why it matters
Without central logging of enrolment and configuration events, an attacker who abuses AD CS to obtain certificates for privileged accounts, or who weakens a template or CA setting to make that possible, can operate without detection and can erase local traces on the CA. Incident responders lose the ability to establish which certificates were issued, to whom and when, which makes containment slow and can leave forged identities trusted long after the intrusion.
Operational notes
Day to day, the CA and the systems that hold templates and AD CS configuration need audit settings that actually generate the events, and a forwarding agent or collector that delivers them to the central log platform. Operators should confirm the feed is still flowing after CA patching, template changes or forwarding-agent updates, because a silent gap defeats the control. Security monitoring teams should treat template and configuration changes as rare, high-signal events and expect a change record behind each one, and should have a view or search for failed enrolment requests so spikes stand out. Keep the CA's local audit log size and retention sensible so events are not overwritten before they are forwarded.
Implementation tips
- The PKI administrator enables auditing on each AD CS certification authority for certificate request events so that both issued and failed enrolment requests are written to the Windows Security log, using the CA audit settings and the matching object access and certification services audit policy.
- The PKI administrator enables auditing of changes to CA configuration (for example CA properties, extensions and policy or exit module settings) through the CA audit settings, and, because certificate templates are Active Directory objects held under Public Key Services in the Configuration partition, works with the Active Directory team to enable Directory Service Changes auditing on the domain controllers and to set a SACL on the Certificate Templates container so that every template modification produces an event (event ID 5136) that names the change and the account that made it.
- The platform or SOC engineering team installs and configures a log forwarding agent or Windows Event Forwarding on every CA and on the domain controllers that record directory service changes to certificate templates, targeting the organisation's central log platform, and confirms events arrive with accurate timestamps and host names.
- The security operations team builds searches and alerts in the central log platform for failed enrolment requests, for unusual volumes of successful requests, and for any template or AD CS configuration change, and routes alerts to the on-call analyst.
- The PKI administrator and change manager agree that every template or AD CS configuration change goes through the change process, and the SOC reconciles logged configuration changes against approved change records on a set schedule.
Audit / evidence tips
- AskAsk for the audit configuration of each AD CS certification authority, including the CA audit filter settings and the applied audit policy.Look atCheck that auditing is turned on for certificate requests and for changes to CA configuration, not just for start and stop events.GoodEvery CA has request auditing and configuration-change auditing enabled, and the settings are enforced by policy rather than set by hand on one server.
- AskAsk to see a sample of successful and failed enrolment request events from the central log platform for a recent period, not from the CA itself.Look atConfirm the events include the requesting account, the template used, the outcome, a timestamp and the CA name, and that both successes and failures appear.GoodBoth outcomes are present in the central platform, the fields are populated, and the volume is consistent with what the PKI team expects for that period.
- AskAsk for the central log records of the most recent certificate template changes and AD CS configuration changes, together with the matching change tickets.Look atCheck that each logged change identifies what was changed and by whom, and that it lines up with an approved change record.GoodEvery template or configuration change in the log has a corresponding approval, and the PKI team can explain any that do not.
- AskAsk how the organisation knows the log feed from each CA is still working, for example forwarding health checks or a missing-source alert.Look atLook for evidence that a stopped or lagging feed from a CA would be noticed, and how quickly.GoodThere is an alert or regular check for CAs that stop sending events, and a record of it firing or being tested.
- AskAsk for the alert rules or saved searches in the central log platform that cover failed enrolment requests and template or configuration changes.Look atCheck that the rules exist, are enabled, and route to someone who acts on them, and look for examples of alerts that were raised and handled.GoodAlerts for configuration changes and unusual enrolment activity are live, have a named owner, and show a history of being triaged.
Cross-framework mappings
How ISM-2132 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.15 | ISM-2132 requires central logging of certificate enrolment requests (successful/unsuccessful) and changes to certificate templates or Mic... | |
handshakeSupports(3)expand_less | ||
| Annex A 5.25 | ISM-2132 requires central logging of certificate enrolment events and AD CS/template configuration changes to detect and investigate misuse | |
| Annex A 8.17 | ISM-2132 requires central logging of certificate enrolment and AD CS/template configuration changes so activity can be investigated | |
| Annex A 8.32 | ISM-2132 requires certificate template and AD CS configuration changes to be centrally logged, alongside enrolment request outcomes | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(3)expand_less | ||
handshakeSupports(6)expand_less | ||
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System hardening
See all Guidelines for system hardening controls, or browse the full ASD ISM library.