Notifications
Clear all
Topic starter
24/06/2026 8:51 pm
TL;DR: ADCS misconfigurations can let attackers impersonate privileged users, and Netwrix says it is adding certificate-enrollment monitoring, suspicious request detection, planned blocking, MCP-based querying, and Bugcrowd validation to address the gap. Legacy identity controls are failing when certificate abuse, privileged account impersonation, and weak auditability converge.
NHIMG editorial — based on content published by Netwrix: Innovation Week: ITDR Innovations and new advances to protect against identity threats
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams reduce risk from vulnerable ADCS certificate templates?
A: Security teams should treat ADCS templates as privileged identity policy, not as routine infrastructure settings.
Q: Why do ADCS misconfigurations create privileged access risk?
A: ADCS misconfigurations create risk because a certificate can function as a trusted identity token.
Q: What do teams get wrong about certificate-based identity threats?
A: Teams often focus on cryptographic strength while ignoring the trust rules around issuance.
Practitioner guidance
- Inventory every privileged ADCS template Document which templates can produce certificates that authenticate as high-value users or systems, then assign explicit owners and review cadence.
- Alert on suspicious enrollment attributes Create detections for unusual subject names, requesters, template selection, and privilege indicators that do not match normal issuance patterns.
- Separate issuance monitoring from audit logging Do not rely on default Windows event logs as the only source of truth for certificate abuse.
What's in the full article
Netwrix's full blog post covers the operational detail this post intentionally leaves for the source:
- Template-by-template ADCS monitoring logic for spotting suspicious certificate enrollments
- Planned blocking behaviour for insecure certificate requests in real time
- How the MCP server surfaces threat and privilege data through chat-based queries
- Bugcrowd-led validation details for testing detection against DCSync-style impersonation
👉 Read Netwrix's analysis of ADCS identity threat detection and MCP integration →
ADCS identity threats: are your controls keeping up?
Explore further
25/06/2026 5:42 am
ADCS abuse is an identity governance failure, not a PKI edge case. When certificate templates can be coerced into privileged authentication, the governance gap sits in issuance policy, not in cryptography. That means teams must treat certificate enrollment as a governed identity event with defined trust boundaries. Practitioners should reframe ADCS from a plumbing service into a high-risk identity control surface.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own ADCS abuse detection and response?
A: ADCS abuse should be jointly owned by identity, PKI, and security operations teams, with clear accountability for template governance and investigation. Because certificate misuse can become privileged access, ownership cannot sit only with infrastructure administrators or only with SOC analysts.
👉 Read our full editorial: Identity threats in ADCS need monitoring, blocking and validation
