ADCS SID Extension for Offline Certificate Requests

Most guidance on KB5014754 stops at "install the patch and the SID extension takes care of itself." That’s true for online certificate templates, where the CA builds the subject from Active Directory and can populate the extension automatically. It is not true for offline templates, where the subject is supplied in the request itself, the exact pattern used by NDES, SCEP, Intune, and most non-domain device enrollment. Offline templates don’t just fail to get the SID extension automatically, they open a genuine privilege-escalation path if the gap isn’t closed correctly, because the default CA behavior is to trust whatever the requester puts in the certificate request rather than independently verifying it.

This post is part of our broader ADCS series, alongside the Complete Guide to Strong Certificate Mapping Enforcement in ADCS, the migration and modernization guide, and the side-by-side vs. in-place decision framework. This piece focuses specifically on offline templates and externally supplied subjects: why they need different handling, how CA policy modules solve it, where the security limitations still are, and how to actually test that your fix works.

TL;DR: Key Takeaways

Online templates get the SID extension automatically, offline templates don’t: the CA can only build the extension from an Active Directory lookup when it controls the subject. When the requester supplies the subject externally, as NDES, SCEP, and Intune all do, that lookup path doesn’t exist by default.
This is not just a functional gap, it’s a security gap: on offline templates, the default CA policy module copies whatever SID extension value appears in the incoming request straight into the issued certificate, without validating it against the actual requester’s identity. A crafted request can claim any SID it wants.
A custom CA policy module is the correct fix, not a workaround: a policy module can intercept issuance for offline templates, perform its own trusted identity lookup, and add the SID extension itself, while explicitly rejecting or stripping any SID value the requester tried to supply directly.
Policy modules reduce this risk, they don’t eliminate every related risk: template hardening (removing ENROLLEE_SUPPLIES_SUBJECT combined with no REQUIRE_UPN wherever possible) and restricting which enrollment protocols and interfaces can reach affected templates still matter, independent of any policy module you deploy.
Test the rejection path, not just the success path: confirming that legitimate offline requests get a correct SID extension is half the validation. Confirming that a request attempting to supply its own SID extension gets rejected or stripped is the other half, and it’s the half most teams skip.

Why Online and Offline Templates Are Fundamentally Different Here

The SID extension Microsoft introduced under KB5014754 binds a certificate to a specific Active Directory account’s Security Identifier, so the KDC can validate the binding cryptographically at authentication time rather than trusting a weaker name-based mapping.

For online templates, the certificate subject is built by the CA directly from the requesting account’s Active Directory attributes. Because the CA already knows exactly which account it’s issuing to, once it’s patched with KB5014754 it can populate the SID extension from that same lookup automatically, with no additional configuration required.

For offline templates, marked with the ENROLLEE_SUPPLIES_SUBJECT flag, the subject name arrives as part of the incoming request instead. This is the standard pattern for NDES-issued SCEP certificates, Intune-managed device certificates, and any enrollment flow where the requesting device or user isn’t a domain-joined identity the CA can look up directly. Because the CA never performs its own Active Directory lookup for these requests, it has no independent basis to determine the correct SID, and by default, it doesn’t try. Certificates issued against offline templates simply don’t get the SID extension at all, which under Full Enforcement mode means every one of them fails Kerberos certificate-based authentication outright.

The Deeper Problem: Offline Templates Don’t Just Miss the Extension, They Trust the Requester

A missing SID extension is a functional problem, certificates fail authentication, and it’s visible immediately as Event ID 39 in your domain controller logs. There’s a second, quieter problem that matters more from a security standpoint.

On offline templates, the default CA policy behavior copies extension values, including a SID extension, directly from the incoming certificate signing request into the issued certificate without independently validating them. If a requester crafts a request that includes its own SID extension, referencing a privileged account’s Security Identifier, and submits it against a template that allows enrollee-supplied subjects without a compensating control like REQUIRE_UPN, the CA has no built-in mechanism to catch that the claimed SID doesn’t match the actual requester’s identity. The certificate that comes back can carry a SID belonging to a completely different, potentially highly privileged, account.

This is the scenario that makes offline template handling a security control, not just a compatibility fix. Simply patching your CA and confirming online templates work correctly leaves this specific path untouched, because it was never the path KB5014754’s baseline fix addressed.

Where This Shows Up in Practice

NDES and SCEP-issued certificates: the standard mechanism for issuing device and user certificates to non-domain-joined or mobile devices, and inherently dependent on offline templates since NDES has no way to build a subject from an AD lookup for external devices.
Intune-managed device certificates: Intune’s Certificate Connector historically issued PKCS and SCEP certificates the same way, through offline templates via NDES. Microsoft added strong certificate mapping support specifically for Intune-issued certificates through an October 2024 update to the Intune Certificate Connector, which is a meaningful vendor-side improvement but only covers Intune’s own issuance path, not every offline-template scenario an organization runs.
Third-party MDM and device management platforms: any integration that requests certificates on behalf of a device or account it manages, rather than the account itself requesting through a domain-authenticated session, typically depends on the same offline template pattern.
Legacy or custom enrollment tooling: internally built enrollment scripts or services that submit requests with a pre-populated subject frequently use offline templates without anyone having revisited whether they need SID handling since KB5014754 shipped.

How a CA Policy Module Adds SID Binding to Offline Requests

A CA policy module sits in the certificate issuance pipeline and gets the opportunity to inspect, modify, or reject a request before the certificate is signed. This is the correct architectural point to solve the offline-template problem, because it lets you separate two decisions the default behavior conflates: whether to add a SID extension at all, and whether to trust a SID value the requester supplied.

A properly built policy module for this scenario does two distinct things:

Adds the SID extension through its own trusted lookup, not the requester’s claim: rather than trusting a SID value in the incoming request, the module performs its own resolution, using the identity of the enrollment agent or connector submitting the request (such as the NDES service account or Intune connector identity) mapped against a known, pre-established account relationship, and writes that resolved SID into the certificate itself.
Enforces a trusted-versus-untrusted source policy on any SID claims in the request: requests arriving through a designated trusted path (an authenticated enrollment agent acting on behalf of a known device-to-account mapping) can have their claimed identity honored after verification. Requests arriving without that trust relationship established have any self-supplied SID extension value stripped or rejected outright, rather than passed through unchecked.

This same trusted-source approach extends naturally to a newer strong-mapping option: Microsoft has previewed a URI name type in the Subject Alternative Name extension as an additional strong mapping mechanism, starting with recent Windows Server preview builds. Because that mechanism has the identical trust problem, an offline-template request can claim any URI value, a policy module handling SID binding correctly should apply the same trusted/untrusted validation logic to that field too, not just the original SID extension.

Security Limitations You Still Need to Plan For

A policy module closes the specific gap it’s designed for, but it is not a substitute for the template and protocol hardening that should already be part of your AD CS posture, and it doesn’t make every enrollment path equally safe by default.

Template hardening still matters independently: any template combining ENROLLEE_SUPPLIES_SUBJECT with no REQUIRE_UPN constraint is a known high-risk configuration (commonly referenced as an ESC1-pattern template in AD CS security research) regardless of whether a policy module is in place. Removing or restricting these templates wherever the business case doesn’t genuinely require them reduces the attack surface a policy module has to defend at all.
Not every enrollment interface behaves identically: AD CS supports several distinct request submission paths (web enrollment, the certificate services RPC/DCOM interface, and the MS-ICPR/CMC submission path used by lower-level and some third-party enrollment clients). Security researchers have publicly documented cases where certificate issuance behavior around auto-generated extensions, including the SID extension, differs depending on which submission path a request arrives through, meaning a control that behaves correctly for one enrollment path can be bypassed if an attacker or misconfigured client uses a different one against the same template. Don’t assume a policy module’s protections are uniformly applied across every possible submission interface without testing each one your environment actually accepts requests through.
A policy module is defense-in-depth, not a single point of trust: treat it as one layer alongside template hardening, enrollment agent permission scoping, and ongoing audit monitoring, not as the sole control standing between an offline template and account impersonation.
Monitoring has to continue after deployment, not stop at go-live: Event IDs 39, 40, and 41 on your domain controllers, alongside your policy module’s own issuance logs, are what tell you whether the fix is actually holding in production, not just in your test lab.

Testing Guidance

Validate both halves of this, the success path and the rejection path, before you consider offline template handling production-ready.

Confirm SID extension issuance on legitimate offline requests: submit a real enrollment through your actual NDES, SCEP, or Intune path and inspect the resulting certificate directly for the SID extension, don’t assume the policy module is firing correctly just because issuance succeeded without an error.
Confirm end-to-end authentication succeeds: take that same certificate through an actual Kerberos PKINIT authentication attempt and verify no Event ID 39, 40, or 41 appears on the relevant domain controller afterward.
Test the rejection path in a lab environment against your own systems: attempt to submit a request through an untrusted or unauthenticated path that includes a self-supplied SID extension value, and confirm the policy module strips or rejects it rather than passing it through. This is the test most teams skip, and it’s the one that actually validates the security control rather than just the compatibility fix.
Test every enrollment interface your CA actually accepts requests through, not just the one your primary use case relies on. If your CA is reachable via more than one submission path, validate the policy module’s behavior on each one independently rather than assuming uniform coverage.
Test the trust-relationship failure mode: temporarily revoke or misconfigure the trusted enrollment agent identity the module relies on, and confirm the result is a clean rejection rather than a silent fallback to trusting requester-supplied values.
Confirm audit logging captures both outcomes: successful trusted-source SID resolution and rejected untrusted-source SID claims should both be visible in your CA’s logs, so a security review can distinguish "working as designed" from "silently failing open."

How Encryption Consulting Can Help

Getting offline template SID handling right requires understanding both the AD CS policy module architecture and the specific enrollment paths, NDES, Intune, third-party MDM, or custom tooling, your organization actually depends on, which is exactly the kind of specialized, low-frequency work most internal teams haven’t built deep expertise in.

Encryption Consulting’s PKI Services team supports this directly:

Offline template and enrollment path audit: identifying every template and integration in your environment that relies on enrollee-supplied subjects, and assessing which ones are currently exposed to the unvalidated SID trust gap.
Policy module design and deployment: building or configuring a CA policy module that adds trusted SID resolution for your specific NDES, Intune, or third-party enrollment paths, with the trusted/untrusted source enforcement built in from the start.
Template hardening alongside the technical fix: reviewing and remediating ENROLLEE_SUPPLIES_SUBJECT templates that don’t need to remain that permissive, so the policy module isn’t your only line of defense.
Full validation testing, covering both the success and rejection paths across every enrollment interface your CA accepts, before you consider the fix production-ready.
Ongoing monitoring setup, correlating domain controller Event IDs 39, 40, and 41 with your CA’s own policy module logs so drift or failure is caught immediately, not discovered during an audit.

If your environment issues certificates through NDES, Intune, or any offline-template path and you haven’t specifically validated SID handling on it, our PKI Services team can assess your exposure and build the fix correctly the first time.

Conclusion

Offline templates and externally supplied subjects need handling that KB5014754’s baseline patch doesn’t provide on its own, because the CA has no independent way to know the correct identity behind a request it didn’t build the subject for. A CA policy module closes that gap properly by resolving the SID through a trusted lookup rather than the requester’s own claim, but it has to be paired with template hardening, enrollment-interface-specific testing, and ongoing monitoring to hold up in practice. Test the rejection path as rigorously as the success path, because a policy module that only ever gets tested against well-behaved requests hasn’t actually been tested against the problem it exists to solve.

Not sure whether your NDES, Intune, or third-party enrollment paths are correctly handling SID binding? Talk to our PKI Services team about auditing your offline templates. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Why doesn’t the SID extension appear on certificates from NDES or Intune? NDES, SCEP, and Intune all rely on offline certificate templates, where the subject is supplied in the request rather than built by the CA from an Active Directory lookup. Because the CA never performs its own identity lookup for these requests, it has no basis to populate the SID extension automatically, unlike online templates where it controls the subject directly.

Is a missing SID extension the only risk with offline templates? No. The more serious issue is that offline templates, by default, allow the CA to copy a SID extension value directly from the incoming request without validating it, which means a crafted request can potentially claim a SID belonging to a different, more privileged account. A correctly built policy module resolves the SID independently rather than trusting the request.

Does Intune’s strong certificate mapping update solve this for all offline templates? No. Microsoft’s October 2024 update to the Intune Certificate Connector added strong mapping support specifically for certificates Intune issues through its own connector. It doesn’t extend to NDES-issued certificates outside that path, third-party MDM platforms, or custom enrollment tooling using offline templates independently.

Is a CA policy module enough to fully secure offline templates? A policy module is a necessary and effective control, but it should be paired with template hardening, removing ENROLLEE_SUPPLIES_SUBJECT configurations without a REQUIRE_UPN constraint wherever possible, and testing across every enrollment interface your CA accepts requests through, since protections built for one submission path aren’t guaranteed to apply uniformly to every other one.

What’s the most commonly skipped test when validating a SID extension fix? Testing the rejection path. Most teams confirm that legitimate requests correctly receive the SID extension and stop there. Confirming that a request attempting to supply its own SID extension value gets stripped or rejected is what actually validates the security control, not just the functional fix.