Strong Certificate Mapping for Intune, Jamf, NDES, and SCEP

Strong certificate mapping guidance almost always assumes a Windows-joined device talking to a Windows CA. That assumption breaks down completely for the devices most enterprises actually struggle with: iPhones and Macs enrolled through Jamf, mixed-platform fleets managed through Intune, and non-domain devices pulling certificates through NDES and generic SCEP. None of these devices can be looked up by the CA the way a domain-joined Windows machine can, which means none of them get the SID extension automatically, and each platform solved the resulting authentication gap differently, on different timelines, with different limitations.

This post is part of our broader ADCS and strong mapping series. For the underlying mechanics of why offline enrollment breaks the default SID extension behavior and how CA policy modules address it, see ADCS SID Extension for Offline Certificate Requests. For the full enforcement timeline and audit events, see the Complete Guide to Strong Certificate Mapping Enforcement in ADCS. This post is the platform-specific playbook: exactly what to configure for Intune, Jamf, NDES, and generic SCEP, and where each platform’s approach still falls short.

TL;DR: Key Takeaways

Intune, Jamf, and generic NDES/SCEP each solved this differently: Intune and Jamf both landed on a Microsoft-defined SAN URI tag carrying the device or user SID, while generic NDES/SCEP deployments outside those platforms need a CA policy module or explicit mapping, since there’s no equivalent built-in mechanism.
Device certificates and user certificates aren’t equally supported everywhere: Intune only supports strong mapping for device certificates on Microsoft Entra hybrid-joined Windows devices; iOS and Android device certificates aren’t supported at all, and user certificates have to be used instead.
Your domain controllers’ OS version matters more than most guidance mentions: offline-issued, SAN URI-mapped certificates from NDES-backed platforms like Intune and Jamf require domain controllers running Windows Server 2019 or later to be recognized as strongly mapped; older domain controllers can log the certificate as unmapped even when the SID is present and correct.
Jamf School lacks the capability entirely: unlike Jamf Pro, Jamf School doesn’t currently support SAN URI SID inclusion, custom certificate templates, or explicit altSecurityIdentities scripting, meaning organizations on Jamf School have no supported path to strong mapping compliance today.
Devices and users with no synchronized SID have no fix available: local macOS accounts or devices with no on-premises Active Directory sync and no Entra ID hybrid identity simply have no SID to bind to, and no platform-level configuration change resolves that.

Why This Needs Platform-Specific Guidance, Not a Single Answer

A domain-joined Windows machine requesting a certificate against an online template lets the CA build the subject directly from its own Active Directory lookup, so the SID extension gets added automatically once the CA is patched. Every device covered in this post breaks that assumption in some way: iOS and Android devices have no Active Directory presence to look up at all, Macs may or may not be AD-bound, and NDES-issued certificates for any platform arrive through an offline template where the subject is supplied in the request rather than derived by the CA. Each of the platforms below solved this differently, and getting your specific platform’s mechanism wrong is why so many organizations pass their pre-enforcement testing and still see authentication failures in production.

Intune: Windows, iOS/iPadOS, and macOS

Microsoft addressed this for Intune-issued certificates through the Intune Certificate Connector, with strong mapping support arriving in connector version 6.2406.0.1001 (the October 2024 update).

The mechanism is a SAN URI tag, not the native SID extension: Intune-issued SCEP and PKCS certificates carry a Subject Alternative Name entry in the format URL=tag:microsoft.com,2022-09-14:sid:<value>, populated from the OnPremisesSecurityIdentifier attribute rather than the certificate extension the CA adds automatically on online templates.
User certificates are supported across all platforms: Windows, iOS/iPadOS, and macOS user certificates all support strong mapping through this mechanism, provided the user account is synced from on-premises Active Directory to Microsoft Entra ID.
Device certificates are only supported for Windows, and only if hybrid-joined: device certificate strong mapping requires the device to be Microsoft Entra hybrid-joined with a SID synchronized from on-premises AD. iOS and Android devices have no equivalent device SID to synchronize, so device certificate strong mapping isn’t supported on those platforms at all, use user certificates for authentication instead where the platform allows it.
Update the Certificate Connector first, then update your certificate profiles: the SID inclusion only applies to new or renewed certificates issued after the connector update and after you’ve added the SAN URI configuration to your SCEP or PKCS profiles, existing certificates won’t retroactively gain it.
Confirm your domain controllers are on Windows Server 2019 or later: this requirement is easy to miss in Intune-specific documentation, but domain controllers on Server 2016 have been observed accepting the certificate while still logging it as unmapped, meaning the certificate technically carries a correct SID but doesn’t get recognized as strongly mapped where it matters.
Watch for the PKCS issuance exception on Windows: an issuance error affecting Windows PKCS certificates under this change was resolved by the November 12, 2024 update (KB5046616), which requires Windows Server 2019 or later on the issuing CA side as well.

Jamf: macOS and iOS Devices

Jamf’s approach uses the same Microsoft-defined SAN URI tag format as Intune, but the path to populating it correctly depends heavily on whether the Mac is AD-bound, Entra-connected, or fully local, and which Jamf product you’re running.

The SCEP payload configuration is straightforward for user certificates: add a Subject Alternative Name entry of type "Uniform Resource Identifier" with the value tag:microsoft.com,2022-09-14:sid: followed by the resolved SID, sourced from an LDAP-derived extension attribute when the device’s assigned user has an on-premises Active Directory account reachable through your existing LDAP integration.
Device or computer certificates need extra work Jamf doesn’t automate out of the box: Jamf’s standard LDAP inventory integration is built to pull user attributes, not computer object attributes, so getting a Mac’s own AD computer SID (as opposed to its assigned user’s SID) typically requires a custom recurring script and a dedicated extension attribute to query and store the computer SID directly from Active Directory when the Mac is domain-bound.
Entra-connected, non-AD-bound Macs have a separate path: for organizations using Jamf Connect with Entra ID rather than binding Macs directly to on-premises AD, the onPremisesSecurityIdentifier attribute synced through Entra can populate the same SAN URI tag, but only when the underlying account actually has an on-premises AD identity synced to Entra in the first place.
Fully local accounts have no available fix: if a Mac user is a local account with no Entra ID connection and no on-premises AD sync, there is no SID anywhere in the identity chain to bind to. No Jamf configuration change resolves this, the account needs to be provisioned with a real AD or Entra-synced identity before strong mapping is achievable at all.
Jamf School does not currently support this path: organizations running Jamf School, rather than Jamf Pro, lack SAN URI SID inclusion support, custom certificate template configuration, and scripting support for explicit altSecurityIdentities mapping. If your Apple device management is on Jamf School and you depend on certificate-based authentication to AD-integrated resources, this is a platform gap with no current workaround, worth escalating to Jamf directly and worth flagging clearly in your own risk register rather than discovering it during an enforcement-driven outage.
The old UPN-in-SAN approach no longer satisfies enforcement: some organizations previously worked around certificate-mapping warnings by injecting the UPN into the certificate’s SAN to match the AD user object. That approach can still authenticate under a weak mapping, but weak mappings are rejected outright under Full Enforcement mode; the SAN URI SID tag is what’s actually required now.

NDES and Generic SCEP (Outside Intune and Jamf’s Built-In Handling)

Not every non-domain or mobile device goes through Intune or Jamf’s own certificate issuance automation. Custom enrollment tooling, third-party MDM platforms, network device authentication, and any SCEP client talking directly to NDES without Intune or Jamf’s specific SID-handling logic sits in a different position.

There’s no equivalent built-in SID tagging mechanism for generic SCEP clients: unlike Intune and Jamf, a generic SCEP client requesting a certificate through NDES doesn’t have a vendor-maintained feature that automatically populates a SAN URI SID tag, the request simply carries whatever subject and extensions the client itself constructs.
A CA policy module is the correct fix for this scenario: as covered in our dedicated post on offline certificate requests, a policy module can perform its own trusted identity resolution for NDES-issued certificates and add the SID extension itself, rather than depending on a client-side feature that may not exist for your specific tooling.
Explicit altSecurityIdentities mapping is a viable fallback for smaller, well-known device populations: for a limited set of devices or service accounts where automating SID resolution isn’t practical, manually configuring an explicit strong mapping type on the account remains a supported, if operationally heavier, path.
The same domain controller OS version requirement applies: confirm your domain controllers are running Windows Server 2019 or later before assuming any offline-issued, SID-mapped certificate from a generic SCEP client will be recognized as strongly mapped.

Common Pitfalls Across Every Platform

Testing only the happy path: confirming that a newly issued certificate carries the correct SID or SAN URI tag isn’t the same as confirming a real Kerberos authentication attempt against a production domain controller succeeds cleanly. Test the full authentication flow, not just certificate content.
Assuming existing certificates are covered: none of these platform-level fixes apply retroactively. Every existing certificate issued before the relevant connector update, configuration change, or policy module deployment still lacks a strong mapping and needs to renew or re-enroll to pick it up.
Overlooking domain controller OS version as a silent failure mode: this is the single most under-documented gotcha across Intune, Jamf, and generic NDES deployments alike, a correctly SID-tagged certificate can still fail to register as strongly mapped if your domain controllers haven’t been upgraded past Server 2016.
Treating device management platform gaps as someone else’s problem: if you’re on Jamf School specifically, or running any MDM platform without native SID-tagging support, that’s an active gap in your authentication posture today, not a future risk, since enforcement is already permanent.

How Encryption Consulting Can Help

Coordinating strong certificate mapping correctly across Intune, Jamf, NDES, and any other enrollment platform in a mixed-device enterprise means understanding both the AD CS side and each platform’s specific SID-handling mechanism, which is a genuinely cross-disciplinary problem most internal PKI or endpoint teams don’t own end to end on their own.

Encryption Consulting’s PKI Services team supports this across your full device estate:

Cross-platform certificate mapping audit: reviewing your Intune, Jamf, and NDES/SCEP configurations together to identify exactly which device and user populations currently lack a valid strong mapping.
Domain controller readiness assessment: confirming your domain controller OS versions actually support recognizing SAN URI-based strong mappings from offline-issued certificates, a check most teams miss entirely.
Platform-specific configuration guidance: correctly configuring Intune Certificate Connector settings, Jamf SCEP payloads and computer SID collection scripting, and NDES policy modules as a coordinated project rather than isolated fixes.
Remediation planning for unsupported platforms: building interim mitigation or migration guidance for environments on Jamf School or other platforms without native SID-tagging support.
Ongoing validation and monitoring, correlating domain controller Event IDs 39, 40, and 41 with issuance logs across every platform in your environment.

If your organization manages a mixed device fleet through Intune, Jamf, or NDES and you haven’t specifically validated strong mapping across all of them, our PKI Services team can audit your full certificate-based authentication posture and close the gaps platform by platform.

Conclusion

Strong certificate mapping enforcement doesn’t have a single fix that applies uniformly across a mixed-device enterprise, it has several, and each one depends on the specific enrollment platform and identity source behind the device or user requesting the certificate. Intune and Jamf both landed on the same Microsoft-defined SAN URI SID tag, but the path to populating it correctly differs by platform, by device type, and by whether the underlying account has a synchronized AD or Entra identity at all. Generic NDES and SCEP deployments outside those platforms need their own solution, typically a CA policy module. Audit every platform in your environment individually, watch specifically for the domain controller OS version gotcha, and treat any platform without native SID-tagging support, including Jamf School, as an active gap rather than an edge case.

Managing a mixed Intune, Jamf, or NDES device fleet and unsure where your strong mapping gaps are? Talk to our PKI Services team about a cross-platform certificate mapping audit. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Does Intune support strong certificate mapping for iOS and Android devices? For user certificates, yes, across all platforms including iOS/iPadOS, macOS, and Windows, provided the user account is synced from on-premises AD to Entra ID. For device certificates specifically, only Microsoft Entra hybrid-joined Windows devices are supported; iOS and Android don’t have an equivalent device SID to synchronize, so device certificate strong mapping isn’t available on those platforms.

Can Jamf School achieve strong certificate mapping compliance? Not currently. Jamf School lacks SAN URI SID inclusion support, custom certificate template configuration, and explicit altSecurityIdentities scripting support, all of which Jamf Pro offers. Organizations on Jamf School relying on certificate-based authentication to AD-integrated resources currently have no supported path to strong mapping compliance on that platform.

Why does my domain controller still show a certificate as unmapped even though it has the correct SID? This is commonly caused by domain controller OS version. Offline-issued, SAN URI-mapped certificates from platforms like Intune and Jamf require domain controllers running Windows Server 2019 or later to be correctly recognized as strongly mapped; domain controllers on Server 2016 have been observed accepting the certificate while still logging it as unmapped.

What happens to Mac users with local accounts that aren’t synced to Active Directory or Entra ID? There’s no available fix at the certificate configuration level. Strong mapping requires a SID, and a fully local macOS account with no on-premises AD sync and no Entra ID hybrid identity has no SID anywhere in its identity chain to bind to. The account needs a real AD- or Entra-synced identity before strong mapping becomes possible.

Do generic SCEP clients outside Intune and Jamf get strong mapping automatically? No. Intune and Jamf each built their own vendor-specific mechanism for populating the SAN URI SID tag. A generic SCEP client talking directly to NDES has no equivalent built-in feature, so achieving strong mapping for that traffic typically requires a CA policy module or explicit altSecurityIdentities mapping instead.