Friday, July 31, 2026
Intune Cloud PKI with HSM
It's 2026 — Time to Rethink Physical vs. Virtual Domain Controllers
It is a question that comes up in almost every Active Directory design conversation: should domain controllers be physical or virtual? For most of the 2010s, the answer was nuanced. For most of the 2020s, it has been shifting decisively toward virtual. But "shifting toward virtual" is not the same as "always virtual" — and in 2026, there are still environments where a physical domain controller is not just acceptable, but the right answer.
This post lays out the honest case for both sides.
Why Virtual Became the Default
The early reluctance to virtualize domain controllers was understandable. Virtualization was a relatively young technology, hypervisors had their own failure modes, and domain controllers were among the most critical infrastructure components in an enterprise. The risks — USN rollback from improper snapshots, VMDK theft, hypervisor compromise granting AD database access — were real, if manageable.
Microsoft addressed most of those concerns systematically. Windows Server 2012 and later support virtualized domain controllers with safeguards to prevent Update Sequence Number (USN) rollback on virtual DCs and the ability to clone virtual DCs. Hypervisor vendors followed with VM encryption, secure boot, and vTPM support. The technical objections largely evaporated.
What remained was the security architecture question — and that is where the real conversation lives in 2026.
The practical advantages of virtual DCs are substantial
Resource consolidation and cost. The ability to host multiple virtual machines on a single physical computer allows those physical computers to be optimized both in terms of cost and availability. Even two hypervisors enable you to increase availability to a level sufficient for most environments. For organizations running two or three domain controllers, the hardware savings from consolidation are significant.
Operational agility. If you have been one of many IT professionals who had to deploy patches to production environments without the ability to test them beforehand, you will greatly appreciate the ability to clone your active domain controllers, isolate the clones, patch them thoroughly, test and re-test, then repeat those steps on production. Snapshot-based testing, rapid DC provisioning, and datacenter-agnostic mobility are genuine operational advantages with no physical equivalent.
Disaster recovery. A virtual DC can be replicated to a secondary site, restored from backup in minutes, and tested regularly without the logistics of physical hardware. Physical DC disaster recovery requires spare hardware, physical access, and significantly longer recovery timelines.
High availability without physical redundancy. Two virtual DCs running on separate physical hosts with shared or replicated storage can deliver resilience that would require four or more physical servers to match — two DCs plus two redundant hardware platforms.
The Security Architecture Problem With All-Virtual
Here is where the conversation gets substantive, and where the all-virtual default deserves scrutiny.
A virtual domain controller runs as a guest on a hypervisor. The hypervisor host — whether it is a vSphere ESXi node, a Hyper-V host, or any other platform — has administrative access to everything running on it. That includes the ability to take a snapshot of the DC's memory and disk, copy the VMDK or VHD, or pause and inspect the running VM.
If an attacker gains administrative access to vCenter Server or an ESXi host, they could potentially access domain controller VMDKs.
This creates a security dependency that does not exist with physical domain controllers: the security of your Active Directory is now partially contingent on the security of your hypervisor management plane. In most enterprise environments, vCenter or SCVMM administrators are not the same people as domain administrators — and they should not be. But the fact that a hypervisor admin could access DC data means the security model must account for that path.
VM encryption addresses the stolen VMDK problem. Encrypted VMs removed from the environment cannot be decrypted without the key management server. But it does not address the live-memory access problem that exists for any administrator with sufficient hypervisor privileges in a running environment.
The practical implication: in an all-virtual DC environment, the hypervisor management plane is effectively Tier 0 infrastructure. If it is not treated that way — hardened, access-controlled, and monitored as rigorously as the domain controllers themselves — the security model has a gap.
Where Physical Domain Controllers Still Make Sense in 2026
Given all of that, there are five scenarios where a physical domain controller remains the right architectural choice.
1. Environments with genuine air-gap or physical security requirements
Operational technology networks, classified government environments, critical infrastructure, and industrial control systems frequently have requirements that prohibit or constrain virtualization. An AD domain supporting manufacturing floor authentication, SCADA systems, or classified workloads may need to run on hardware that is physically isolated, tamper-evident, and not shared with any other workload. Virtual infrastructure adds a layer of complexity and attack surface that these environments cannot accept.
2. The hypervisor management plane cannot be hardened to Tier 0
This is more common than it sounds. Many organizations have a virtualization team that manages the hypervisor environment — vCenter, ESXi hosts, storage — but that team is not subject to the same access controls, monitoring, and hardening as Active Directory administrators. If you cannot bring your hypervisor management plane to Tier 0 security standards — dedicated admin accounts, PAWs, MFA, limited network access, comprehensive auditing — then running all your domain controllers as VMs on that platform is an architectural risk.
A single physical DC, properly hardened, breaks that dependency. The physical machine requires physical access. The NTDS.dit is on local storage. There is no hypervisor admin path to the AD database.
3. Branch offices and remote locations with poor or unreliable connectivity
An RODC is designed primarily to be deployed in remote or branch office environments, which typically have few users, poor physical security, relatively poor network bandwidth to a hub site, and personnel with limited knowledge of IT. A physical RODC at a branch office provides local authentication without requiring WAN connectivity for every logon — critical for locations with unreliable internet or no direct path to the datacenter.
The RODC is specifically designed for environments where you cannot guarantee physical security of the hardware. Typically, an RODC would be allowed to retrieve and cache credentials only for accounts that belong to the same physical location and have an equivalent or lower level of physical security. Tier 0 credentials should never be cached on an RODC — but for local user authentication in a branch, it is the right tool and often needs to be physical because there is no hypervisor infrastructure at that location.
4. Resilience against shared failure domains — but physical is not the only answer
An all-virtual DC environment on a single hypervisor platform has a shared failure mode: if the cluster fails — storage corruption, network partition, firmware bug, or a security incident affecting the management plane — all domain controllers can become unavailable simultaneously.
Historically the answer to this was to keep one physical DC outside the virtual environment as a resilience anchor. That still works, but it is no longer the only option, and often not the best one.
Distributing across independent platforms achieves the same goal without physical hardware. Domain controllers in Azure and AWS, or Azure and an on-premises hypervisor, or two different hypervisor clusters with genuinely separate storage and management planes, eliminate the shared failure domain just as effectively. A vCenter compromise does not touch your EC2 instances. An Azure regional outage does not affect your on-premises cluster. The failure domains are genuinely independent — arguably more so than a physical DC sitting in the same datacenter, on the same power feed and network core, as the hypervisor cluster it is supposed to survive.
This does introduce cross-platform replication traffic and additional network dependencies to design around, and it means managing DC infrastructure across two vendor ecosystems. But for organizations already operating in multiple clouds, it is a smaller architectural lift than maintaining physical server hardware for a single role.
The more important point: backup discipline matters more than the physical/virtual distinction. No DC placement strategy — physical, virtual, single-cloud, multi-cloud — substitutes for a tested backup and restore capability. Forest recovery is the scenario that actually threatens organizational survival, and it is a scenario that a spare physical DC does not solve. If your entire forest is compromised by ransomware or a malicious deletion, having one DC on physical hardware does not help you — it is replicating the same corrupted data as everything else.
What helps is: System State backups stored offline and immutable, a documented and rehearsed forest recovery procedure, and an actual test restore performed on a schedule rather than assumed to work. Most organizations have the first, some have the second, and very few have genuinely done the third.
The uncomfortable question for any AD environment, regardless of DC placement: when was the last time you actually restored a domain controller from backup and verified the forest came back intact? If the answer is "never" or "years ago," that is a larger risk than whether your DCs are physical or virtual.
5. Regulatory or compliance requirements mandating physical separation
Some compliance frameworks — particularly in financial services, healthcare, and government — have requirements around workload isolation, dedicated hardware for sensitive systems, or prohibitions on co-tenancy that effectively mandate physical domain controllers. This is becoming less common as compliance frameworks mature to accommodate virtualization, but it has not disappeared.
The Bigger Shift: Cloud-Only Endpoints Are Shrinking the DC Footprint
There is a change happening underneath this entire debate that deserves more attention than it usually gets, because it changes the shape of the question.
Historically, the primary driver for a large, geographically distributed fleet of domain controllers was not resilience — it was logon performance. Specifically, Group Policy processing. When a domain-joined workstation authenticates, it needs to reach a domain controller in its site to process GPOs, retrieve the user's policy set, apply drive mappings, run logon scripts, and complete the logon sequence. Every millisecond of latency between the workstation and the nearest DC translates directly into perceptible logon delay for the user.
That is why organizations built out DCs at every regional office, every campus, every location with more than a handful of users. Not because they needed twelve copies of the AD database for redundancy, but because users in Frankfurt should not be authenticating against a domain controller in Phoenix and waiting thirty seconds for their desktop to appear.
As workstations move to Entra-joined and Intune-managed, that driver disappears.
An Entra-joined device does not process Group Policy. It receives configuration from Intune — MDM policy delivered over the internet, on a sync cycle, with no dependency on proximity to a domain controller. The user authenticates against Entra ID, not against a local DC. Logon performance is a function of internet connectivity and Entra ID service availability, not of DC site topology.
The practical consequence is significant: as the domain-joined workstation fleet shrinks, the justification for a distributed domain controller footprint shrinks with it.
What remains on-premises and still needs local AD authentication tends to be servers, service accounts, legacy line-of-business applications, file shares, print services, and specialized workloads — none of which are as latency-sensitive as interactive user logon, and most of which live in the datacenter anyway, close to where the DCs would be consolidated.
What this enables architecturally
This opens up a consolidation option that would have been unthinkable ten years ago: collapse the entire domain controller footprint into a small number of well-secured locations.
That could mean a single hardened physical datacenter with a properly controlled hypervisor environment. It could mean Azure — DCs running as IaaS VMs in a dedicated subscription with restricted network access and Azure-native security controls. It could mean AWS EC2 instances in a locked-down VPC. It could mean a combination: one region in Azure, one in a physical datacenter, replicating between them.
The advantage is concentration of security effort. Instead of trying to physically secure and monitor twelve domain controllers scattered across regional offices — where the server closet is sometimes genuinely a closet, and physical access control is a lock that six people have keys to — you secure two or three locations properly. Fewer DCs means fewer patch targets, fewer monitoring blind spots, fewer physical access risks, and a dramatically smaller Tier 0 attack surface.
For most organizations mid-transition, this is the pragmatic interim state: consolidate the DC fleet as the domain-joined endpoint population declines, run those consolidated DCs in environments you can actually secure to Tier 0 standards, and let the footprint shrink further as the last domain-joined workloads migrate or retire.
The caveats worth naming
This consolidation is not free of tradeoffs, and two deserve explicit mention.
Remaining domain-joined endpoints still care about latency. If you still have a manufacturing site, a lab environment, or a regional office running domain-joined workstations, consolidating all DCs to a central location will degrade their logon experience. The consolidation should track the migration, not lead it. Measure which sites still have meaningful domain-joined populations before removing their local DC.
Cloud-hosted DCs introduce a network dependency for on-premises authentication. If your DCs live in Azure and your file servers live on-premises, every Kerberos ticket request traverses your ExpressRoute or VPN connection. That link becomes Tier 0 infrastructure. It needs the availability, redundancy, and monitoring appropriate to that classification — because if it drops, on-premises authentication stops.
A common mitigation is keeping at least one DC on-premises specifically to serve local server authentication while the majority of the fleet consolidates to cloud or a central datacenter. Which brings the discussion back to the hybrid architecture below.
The Hybrid Architecture: Best of Both
For most enterprise environments, the practical answer in 2026 is not physical or virtual — it is a deliberate combination.
A reasonable reference architecture:
Two virtual domain controllers in the primary datacenter or cloud region, running on separate physical hosts with VM encryption enabled and the hypervisor management plane treated as Tier 0 infrastructure. These DCs handle the majority of authentication load and benefit from the operational advantages of virtualization — snapshot testing, rapid recovery, high availability through hypervisor clustering.
A third domain controller on an independent platform — this is where the design choice actually lives. It can be a physical server outside the virtual environment, or an IaaS VM in Azure or AWS. What matters is that its failure domain is genuinely independent of the primary hypervisor cluster: separate management plane, separate storage, separate power and network path. For organizations already operating in a public cloud, the cloud option is usually the lower-friction choice and provides better geographic separation than a physical server in the same building. For air-gapped or compliance-constrained environments, physical remains the answer.
A tested backup and recovery capability — not an architectural component, but the one that matters most. System State backups stored immutably and offline, a documented forest recovery runbook, and a scheduled test restore that is actually performed. This is independent of whether any DC is physical.
Physical RODCs at branch offices where local authentication is required and no hypervisor infrastructure exists — but only where a meaningful domain-joined population still exists. As those endpoints migrate to Entra join, the branch RODC becomes a candidate for retirement rather than replacement.
This architecture captures the operational benefits of virtualization for the majority of DC workload while preserving the security and resilience advantages of physical hardware where they matter most.
The trajectory matters as much as the current state
Worth designing with the endpoint migration timeline in mind. An architecture that is correct today may be over-provisioned in eighteen months. If 60 percent of your workstation fleet is still domain-joined, you need DC coverage that reflects that. If you expect that number to be 15 percent by next year, do not sign a three-year hardware refresh for twelve regional domain controllers.
The right question during design is not just "what do we need now?" but "what is the smallest DC footprint we can converge on, and what has to migrate first to get there?"
What to Watch Out For in Either Model
Regardless of physical or virtual, several failure modes are universal and worth calling out explicitly.
Snapshots are not backups. A VM snapshot is a point-in-time consistency mechanism, not a backup. Reverting a domain controller to a snapshot can cause USN rollback and AD replication failures. Use Windows Server Backup or a backup solution with AD-aware VSS integration. Test restores regularly.
PDC Emulator placement matters. The PDC Emulator handles time synchronization, password change replication, and Group Policy processing priority. It should be on stable, well-connected infrastructure. In a mixed physical/virtual environment, the PDC Emulator often belongs on the physical DC.
FSMO roles and single points of failure. FSMO roles are not automatically failed over — if the role holder goes offline, certain operations stop working. Know where your FSMO roles are, document the seizure procedure, and test it.
Physical DC patching discipline. Virtual DCs benefit from snapshot-based patch testing. Physical DCs do not. Physical DC patching requires more disciplined change management and tested rollback procedures. This is an operational cost of physical infrastructure that should be factored into the decision.
The Verdict for 2026
Virtual domain controllers are mature, well-supported, and the right default for most environments. The historical concerns about USN rollback and VMDK security have been addressed by both Microsoft and the major hypervisor vendors. For organizations with a well-managed hypervisor environment, running all domain controllers as virtual machines is a defensible and operationally superior architecture.
But the all-virtual default has a security assumption embedded in it: that the hypervisor management plane is treated as Tier 0 infrastructure. Organizations that have not made that architectural commitment — and many have not — are carrying a security gap they may not have fully characterized.
Physical domain controllers are not obsolete, but the list of scenarios that genuinely require them has narrowed considerably. Air-gapped and classified environments still need them. Branch offices with no hypervisor infrastructure and a remaining domain-joined population still need them. Compliance frameworks mandating dedicated hardware still require them. And environments where the hypervisor management plane cannot be brought to Tier 0 standards benefit from at least one DC outside that dependency.
What no longer justifies physical hardware on its own is resilience against hypervisor failure. Distributing domain controllers across genuinely independent platforms — Azure and AWS, or cloud and on-premises, or two separate hypervisor clusters with distinct management planes — achieves that goal more effectively than a physical server sitting on the same power feed and network core as the cluster it is meant to survive.
And none of it substitutes for a tested backup and restore capability. Forest recovery is the failure mode that actually threatens the organization, and no DC placement strategy solves it. Immutable offline System State backups, a documented recovery runbook, and a test restore that has actually been performed matter more than any decision about where the DCs run.
But the more consequential shift is not physical versus virtual — it is how many domain controllers you need at all. The distributed DC fleet was built to serve Group Policy processing for domain-joined workstations at acceptable logon latency. As those workstations become Entra-joined and Intune-managed, that requirement evaporates, and the DC footprint can consolidate into a small number of properly secured locations — a hardened physical datacenter, an Azure or AWS environment with restricted access, or a combination.
That consolidation is where the real security win is. Two or three well-secured domain controllers in environments you can actually monitor and control are more defensible than twelve scattered across regional offices with inconsistent physical security and patch discipline.
So there are three questions worth asking, in order:
First: how many domain controllers does our remaining domain-joined workload actually require, and where?
Second: for the ones we keep — what does our hypervisor management plane look like, and are we comfortable with what that means for our domain controller security model?
Third: when did we last perform an actual test restore and verify the forest came back intact?
The first sizes your footprint. The second tells you whether one of them needs to sit outside the hypervisor dependency. The third is the one most organizations cannot answer confidently — and it is the one that matters most.
SCEP vs PKCS: choosing the right certificate delivery method for Intune and AD CS
SCEP vs PKCS: choosing the right certificate delivery method for Intune and AD CS
A practical comparison of the two certificate enrollment options available in the Intune Certificate Connector — and why the choice matters more than most guides suggest.
When you deploy certificates to Intune-managed devices using Active Directory Certificate Services as your CA, you have two delivery mechanisms available through the Intune Certificate Connector: SCEP (Simple Certificate Enrollment Protocol) and PKCS (delivered as PKCS#12 PFX bundles). Most guides treat this as a minor configuration detail. It isn't.
The choice between SCEP and PKCS determines where private keys are generated, whether they can ever be extracted, how your infrastructure is exposed, and ultimately how strong your certificate-based authentication actually is. In regulated environments — PCI DSS, Zero Trust architectures, or anywhere you care about key security — making the right choice here is fundamental.
This post covers both options in depth: how they work mechanically, their security implications, how each behaves across Windows, macOS, and iOS, and the decision criteria that should drive your choice.
1 What SCEP and PKCS actually do
The fundamental difference between SCEP and PKCS comes down to two questions: where is the private key generated? and Do you accept the additional overhead for running a NDES service?
Private key never leaves the device.
Private key transits the connector at delivery.
This distinction has cascading implications for security, infrastructure design, and operational complexity — all of which we'll work through below.
2 SCEP in depth
SCEP is the older and more widely supported protocol. It was designed specifically to solve the problem of enrolling large numbers of devices for certificates in a scalable way, and it does so by having each device manage its own key material.
Infrastructure requirements
SCEP via Intune requires three components working in concert:
- The Intune Certificate Connector — installed on a Windows Server, handles the trust relationship between Intune and your on-premises CA
- NDES (Network Device Enrollment Service) — a Windows Server role service that implements the SCEP protocol and acts as the gateway between devices and AD CS. Must be on a dedicated member server, not on the CA itself
- AD CS Issuing CA — signs the certificate requests forwarded by NDES
The residual consideration with NDES is therefore operational rather than exposure-based: it is still an additional server role to deploy, patch, and keep healthy alongside the connector and CA, and its default request rate limiting may need tuning for bulk enrollment. But the "dangerous internet-facing box" framing applies only to the legacy publishing model — not to the connector-based Intune deployment.
Pros and cons
- Private key generated on device - never exists anywhere else in the infrastructure
- TPM key binding on Windows: key generated inside TPM, hardware-bound, non-exportable
- Secure Enclave binding on iOS with ECC P-256 keys - automatic on supported hardware
- No PKCS#12 bundle ever in transit - only CSR (public) and certificate flow between systems
- Gold standard PKI design - aligns with RFC 5280 intent that keys are generated by the end entity
- Strong fit for Zero Trust and high-security regulated environments
- NDES server required - additional infrastructure to deploy, patch, and monitor
- NDES is one more server role to deploy, patch, and keep healthy (though not internet-facing in the connector model)
- Three components must all be healthy simultaneously (Connector + NDES + CA)
- NDES default rate limiting can throttle bulk enrollment events without tuning
- Device must reach the Intune service to renew - long-offline devices can hit a bootstrapping problem at expiry
- More complex to troubleshoot than PKCS when enrollment fails
3 PKCS in depth
The PKCS option (sometimes called PFX delivery in Intune documentation) takes a fundamentally different approach: instead of the device generating its own key, the Intune Certificate Connector requests a certificate from AD CS on behalf of the device, packages the certificate and private key as a PKCS#12 bundle, encrypts it using a device-specific key, and delivers it through the Intune MDM channel.
Infrastructure requirements
PKCS delivery is simpler: just the Intune Certificate Connector and AD CS. No NDES. The connector communicates outbound to Intune and inbound to AD CS using its service account credentials. Devices receive their certificates through the standard Intune MDM channel — the same channel used for all other policy delivery.
What about the PFX password? Doesn't someone have to type it?
A reasonable concern: if the private key is delivered inside a password-protected PFX, does a user or admin have to enter a password, and does that password have to be distributed or stored somewhere? The answer is no — and understanding why matters.
In the on-demand PKCS profile flow (per-device certificates for Wi-Fi and VPN), the PFX password is purely a transport wrapper. It is generated and handled automatically, encrypted for the specific target device, and consumed exactly once when the device installs the certificate. The moment the key is imported into the device's key store — the TPM/KSP on Windows, or Keychain/Secure Enclave on Apple platforms — the transport password is discarded. It is never re-entered, never typed by a user, and never needs to be distributed. From that point the key is protected by the hardware key store, not by any password.
The TPM question — correcting a common misconception
A common assumption is that PKCS delivery means the private key cannot be hardware-bound. On Windows, this is not entirely true. When you configure the Intune PKCS certificate profile to use the TPM KSP (Microsoft Platform Crypto Provider), Windows imports the delivered private key directly into the TPM during installation. Once inside the TPM, the key is hardware-bound and non-exportable — equivalent in protection to a SCEP-enrolled TPM key after the point of delivery.
The difference that remains: with SCEP + TPM, the key is generated inside the TPM and never exists outside it. With PKCS + TPM, the key exists transiently on the connector server during packaging before being imported into the TPM. For most organisations this distinction is an acceptable residual risk; for the most sensitive environments it is meaningful.
This TPM import capability is Windows-only. macOS and iOS have no equivalent mechanism for importing an externally-delivered key into the Secure Enclave.
Pros and cons
- No NDES required — simpler infrastructure with fewer components
- One fewer server role — no NDES to deploy, patch, or maintain
- Delivery via Intune MDM channel — no device-to-NDES connectivity needed
- More predictable throughput for large bulk enrollments
- TPM key binding achievable on Windows via TPM KSP configuration
- Easier to troubleshoot — fewer components in the enrollment chain
- Works well for user certificates pre-provisioned before user login
- Private key transits the connector server transiently during packaging
- No hardware key binding on macOS or iOS — software key storage only
- Certificate template must allow key export at issuance (CT_FLAG_EXPORTABLE_KEY)
- Connector server handles key material — must be treated as a sensitive, hardened host
- No true hardware key attestation even when TPM KSP is used on Windows
- Weaker key security model than SCEP for non-Windows platforms
4 Platform behaviour: Windows, macOS, and iOS
The security characteristics of SCEP vary significantly by platform — and understanding these differences is essential for designing a cross-platform certificate deployment.
Windows
Windows has the richest options for hardware key binding. With SCEP, configuring the certificate profile to use the TPM KSP causes the key pair to be generated inside the TPM — the key never exists in software. With PKCS, the same TPM KSP setting causes Windows to import the delivered key into the TPM. Both options give you hardware-bound keys post-installation; only SCEP gives you a key that was never outside hardware at any point.
Both RSA and ECC keys can be stored in the Windows TPM, giving you flexibility on key algorithm choice.
macOS
On macOS, the private key is always generated on the device (SCEP) or installed to the System Keychain (PKCS). Hardware binding to the Secure Enclave is possible with SCEP on Apple Silicon Macs (M1/M2/M3 and later) and Intel Macs with T2 chips, but only with ECC P-256 keys — RSA keys cannot be stored in the Secure Enclave on macOS.
Critically, Intune cannot guarantee or force Secure Enclave storage on macOS through the SCEP profile — it is determined by the OS based on hardware capability and key algorithm. This is a meaningful difference from Windows where you can explicitly mandate TPM KSP.
iOS and iPadOS
iOS has the most straightforward hardware binding story, and it works automatically. All modern iPhones and iPads (A7 chip and later — effectively everything from iPhone 5s onward) have a Secure Enclave. When a SCEP enrollment uses ECC P-256 as the key type, iOS stores the private key in the Secure Enclave automatically — no additional configuration is needed. The key is hardware-bound and cannot be extracted.
RSA keys on iOS are stored in the software Keychain, which is protected by hardware-encrypted storage and the device passcode, but is not Secure Enclave-bound. For this reason, always use ECC P-256 for iOS SCEP deployments.
Platform comparison
| Capability | Windows | macOS | iOS / iPadOS |
|---|---|---|---|
| SCEP key generation location | Device (software or TPM) | Device (software or Secure Enclave) | Device (software or Secure Enclave) |
| PKCS key origin | Connector → imported to TPM | Connector → software Keychain only | Connector → software Keychain only |
| Hardware binding (SCEP) | Yes — TPM | ECC only, not guaranteed | Yes — ECC auto-SE |
| Hardware binding (PKCS) | Yes — TPM KSP | No | No |
| Force hardware storage via Intune | Yes | No | Automatic with ECC |
| Best key algorithm for HW binding | RSA or ECC | ECC P-256 | ECC P-256 |
| Auto-renewal via Intune | Yes | Yes | Yes |
| Cert removed on Intune unenrollment | Yes | Yes | Yes |
5 TPM and hardware key storage — the full story
Hardware key storage is the single most important security dimension in this comparison. Here's the complete picture across both options and all platforms.
SCEP + TPM (Windows) — strongest option
Configure the Intune SCEP profile to use Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. The key pair is generated inside the TPM during enrollment. The private key never exists in software at any point — it is created in hardware, lives in hardware, and operations that use it (signing, decryption) happen inside the hardware. It cannot be exported by anyone, including administrators.
PKCS + TPM KSP (Windows) — strong, with a caveat
Configure the Intune PKCS profile to use the TPM KSP and set Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. Windows imports the delivered private key into the TPM during PFX installation. Post-installation, the key is hardware-bound and has the same protection properties as a SCEP TPM key. The caveat: the private key existed on the connector server transiently during PFX packaging. For most organisations this is an acceptable residual risk — the window is brief and the connector should be a hardened, access-controlled server. For the highest-sensitivity environments, SCEP + TPM removes this risk entirely.
SCEP + ECC P-256 (iOS) — strong and automatic
No special configuration needed. Any iOS device on A7 silicon or later (iPhone 5s / iPad Air 1st gen and later — effectively all devices in active use) will automatically store an ECC P-256 private key in the Secure Enclave. The key cannot be extracted. Just set the Intune SCEP profile to use ECC P-256 and iOS handles the rest.
SCEP + ECC P-256 (macOS) — best effort
On Apple Silicon and T2-equipped Intel Macs, macOS may store an ECC P-256 SCEP key in the Secure Enclave, but this is not guaranteed or configurable from Intune. It is hardware-dependent and OS-determined. On older Intel Macs without a T2 chip, keys will be in the software Keychain regardless of algorithm. This is the weakest hardware binding story of any platform.
6 Key archival and recovery — the deciding factor
There is one architectural difference between SCEP and PKCS that trumps almost everything else, and it comes down to a single question: does this certificate's private key ever need to be recovered?
SCEP cannot archive keys — by design
In SCEP, the private key is generated on the device and never leaves it. The CA only ever sees a certificate signing request containing the public key. This means there is nothing for the CA to archive — the private key simply does not exist anywhere the CA can capture it. Active Directory Certificate Services key archival, using a Key Recovery Agent (KRA), requires the private key to be escrowed at the CA at the moment of issuance. That is fundamentally incompatible with the SCEP model. If you need recoverable keys, SCEP is architecturally ruled out.
For authentication certificates, this is a feature — not a limitation
Here's the key insight: for authentication certificates — Wi-Fi, VPN, 802.1X — you never want to recover the private key. If a device is lost, wiped, or the key is otherwise gone, the correct response is simply to issue a new certificate. There is no data locked behind an authentication key, so there is nothing to recover. A non-recoverable, TPM-bound, non-exportable key is exactly what you want. SCEP delivers precisely this.
For encryption certificates, recovery is mandatory
Encryption certificates are the opposite case. If a user loses the private key for an S/MIME email certificate or an EFS file-encryption certificate, every message and every file ever encrypted to that key becomes permanently unreadable. For these use cases, the key must be archived at the CA so it can be recovered — which means it must be generated in a way the CA can escrow. SCEP cannot do this; you need a PKCS flow with key archival enabled on the CA and a configured Key Recovery Agent.
| Use case | Key recoverable? | Right approach |
|---|---|---|
| Wi-Fi / VPN / 802.1X client auth | No — reissue if lost | SCEP (or PKCS), TPM-bound, non-exportable, no archival |
| S/MIME email encryption | Yes — losing it loses all encrypted mail | PKCS with CA key archival + Key Recovery Agent |
| EFS / data-at-rest encryption | Yes — losing it loses all encrypted files | PKCS with CA key archival + Key Recovery Agent |
7 Side-by-side comparison
| Factor | SCEP | PKCS (PFX delivery) |
|---|---|---|
| Private key generation | On the device — always | On the AD CS server / connector |
| Private key in transit | Never — only CSR and signed cert flow | Transits connector transiently during packaging |
| NDES required | Yes | No |
| Infrastructure complexity | Higher — Connector + NDES + CA | Lower — Connector + CA |
| Windows TPM binding | Yes — key generated in TPM (strongest) | Yes — key imported to TPM (strong) |
| iOS Secure Enclave binding | Yes — automatic with ECC P-256 | No |
| macOS Secure Enclave binding | Best effort with ECC P-256 on Apple Silicon | No |
| Key attestation | Possible on Windows with TPM | Not possible |
| Certificate template exportable key flag | Not required | Required at issuance |
| Key archival / recovery possible | No — key never leaves device, cannot be escrowed | Yes — supports CA key archival for recovery |
| Suits authentication certificates | Yes — ideal (non-recoverable is a feature) | Yes |
| Suits encryption certificates (S/MIME, EFS) | No — cannot recover lost keys | Yes — with archival enabled |
| Bulk enrollment throughput | Limited by NDES rate limiting (tunable) | More predictable — connector-controlled |
| Offline device renewal risk | Similar — device reaches Intune to renew (not NDES directly) | Lower — MDM channel used for delivery |
| PCI / regulated environments | Preferred — stronger key model | Acceptable with TPM KSP (Windows only) |
| Operational overhead | Higher — more components to manage | Lower — simpler architecture |
8 Which one should you choose?
The right answer depends on your security requirements, device mix, and operational capacity. Here's the decision breakdown:
- You need the strongest possible key security model — key never leaves the device
- You have iOS or macOS devices and want Secure Enclave key binding
- Hardware key attestation is a requirement
- The certificates are for authentication only — no key recovery needed (reissue on loss)
- You have operational capacity to deploy and maintain NDES securely
- Your device estate includes significant non-Windows platforms
- You want simpler infrastructure with no NDES to manage
- Your estate is primarily Windows and TPM KSP covers your key binding needs
- You need predictable throughput for large bulk enrollment events
- You're pre-provisioning user certificates before first login
- You need key archival and recovery — S/MIME, EFS, or any encryption certificate
- Operational simplicity is a priority and key transit risk is acceptable
- You want fewer components to troubleshoot and maintain
9 The SCEPman angle
If the main drawback of SCEP is the operational overhead of running and maintaining NDES, it's worth knowing that this problem is solvable without switching to PKCS.
SCEPman: SCEP security without NDES complexity
SCEPman (from Glueck Kanja GAB) is a cloud-native SCEP and OCSP service that runs in your Azure tenant as an App Service. It implements the SCEP protocol natively in the cloud, replacing NDES entirely. Devices enroll via SCEP and generate their own key pairs locally — the full SCEP security model, including Secure Enclave binding on iOS with ECC P-256 and TPM binding on Windows.
The CA private key is protected by Azure Key Vault with HSM backing (FIPS 140-2 Level 2+), and revocation can be linked to Intune device compliance state in real time — automatically revoking certificates when devices fall out of compliance or are unenrolled.
If you want the strongest key security model (SCEP, device-generated keys, hardware binding across all platforms) without the operational burden of running and hardening an on-premises NDES server, SCEPman is architecturally the cleanest answer.
Key takeaways
- SCEP generates keys on the device — the private key never exists anywhere in your infrastructure. PKCS generates keys on the connector and delivers them to the device. This is the fundamental security difference.
- PKCS + TPM KSP on Windows imports the delivered key into the TPM, giving hardware-bound protection post-delivery — but the key still transited the connector. SCEP + TPM generates the key in the TPM and it never leaves hardware.
- On iOS, SCEP with ECC P-256 automatically stores private keys in the Secure Enclave — no configuration required. PKCS on iOS is always software-stored.
- SCEP requires NDES — but in the Intune Certificate Connector model it is not internet-facing. The connector polls Intune outbound; devices never talk to NDES. Both servers can be fully isolated. The real cost of NDES is operational (one more role to run), not exposure. PKCS requires only the connector and your CA.
- For mixed Windows/macOS/iOS environments, SCEP provides a more consistent security posture — hardware binding works across all platforms. PKCS hardware binding is Windows-only.
- SCEP cannot archive keys for recovery — the CA never sees the private key. This makes it perfect for authentication certificates (reissue on loss) but rules it out for encryption certificates like S/MIME or EFS, which need an archival-capable PKCS flow. Split your architecture along these lines.
- The PFX password in the on-demand flow is a transport wrapper only — generated automatically, consumed once at install, then discarded as the key enters the TPM. No user types it, no one distributes it. Don't confuse it with the admin-supplied password in the separate imported-PFX/S-MIME feature.
- SCEPman/Cloud PKI eliminates the NDES problem while retaining full SCEP key security — worth evaluating if NDES complexity is your main objection to SCEP.
Saturday, May 30, 2026
AD PKI vs Cloud-based PKI
Public Key Infrastructure is one of those foundational technologies that most organizations installed once, pointed at Active Directory, and largely forgot about — until something breaks, a certificate expires at 2am on a Sunday, or an auditor starts asking uncomfortable questions about your root CA.
Now, with cloud-based PKI services maturing rapidly and Microsoft pushing hard toward cloud-native identity, the question of whether to keep running an on-premises AD-integrated PKI or migrate to a cloud-based alternative is coming up in more and more architecture conversations.
The honest answer is: it depends. But the factors it depends on are worth understanding clearly before you make the call.
In this blog I am focusing on certificates for end points for Wi-Fi authentication.
Over the years Microsoft has never made a big effort to b able to issue certificates to non-AD-integrated Windows platforms. This is something you should use a MDM solution for and that MDM solution can either use a cloud-based PKI or keep using the AD PKI. Other aspects like RADIUS authentication require a separate discussion. All cloud-based solutions are based on the number of users, while the AD PKI requires more or less only the server license.
What We Mean by "AD PKI"
When most organizations say they have a PKI, they mean Microsoft Active Directory Certificate Services (AD CS) — a Windows Server role that has been the default enterprise PKI for two decades. It integrates tightly with Active Directory, auto-enrolls certificates to domain-joined machines via Group Policy, and handles everything from user authentication certificates to machine identity, S/MIME email signing, Wi-Fi EAP-TLS, and internal TLS for servers and web applications.
It works well. It is deeply embedded. And for many organizations, it is also unmaintained, under-documented, and running on hardware that predates the current IT team.
Cloud-based PKI comes in several flavors: Microsoft Cloud PKI (part of Intune / Microsoft Entra Suite), Glueck Kanja SCEPman, SCEP and PKCS integrations with third-party services like DigiCert, Sectigo, or GlobalSign, and purpose-built cloud PKI platforms like Smallstep, Keyfactor, or Venafi. Each has a different architecture and a different value proposition, but they share a common premise: move certificate lifecycle management off your infrastructure and into a managed service.
The Case for Keeping AD PKI
It works — and you've already paid for it
AD CS is included in Windows Server. If you are running a hybrid Active Directory environment, you already have the licensing, the infrastructure, and the integration in place. For organizations with a significant on-premises footprint - domain-joined endpoints, on-premises servers, legacy applications - AD CS is the path of least resistance.
Deep Group Policy integration
AD CS integrates with Group Policy in ways that cloud PKI services cannot fully replicate for legacy workloads. Certificate auto-enrollment via GPO is mature, well-understood, and effectively zero-touch for end users and devices once configured correctly. For Windows environments with a large base of domain-joined endpoints, this integration eliminates a significant category of operational overhead. GPO deployment is not working anymore of all endpoints are becoming cloud-only.
Air-gapped and high-security environments
For organizations with genuine air-gap requirements — classified government environments, operational technology networks, critical infrastructure — an on-premises PKI is not optional, it is a compliance requirement. A cloud-based PKI that requires internet connectivity for certificate issuance is architecturally incompatible with these environments regardless of how mature the service is.
Control and auditability
With AD CS you own every component: the root CA (ideally offline), the issuing CA, the certificate database, the CRL distribution points. For organizations with strict compliance requirements around cryptographic key custody — financial services, healthcare, federal contractors — that level of control has real value. You know exactly where your private keys are. You can demonstrate it to an auditor. This also means on a lot of cases that Hardware Security Modules are required and adding complexity and costs.
The Case for Moving to Cloud PKI
AD CS has an operational debt problem
The average enterprise AD CS deployment was designed and implemented years ago by someone who may no longer work there. Certificate templates have accumulated. The root CA may be running on aging hardware with no documented recovery procedure. CRL distribution points may reference internal hostnames that no longer exist. The private keys for the root CA may be stored on the CA server itself rather than in an HSM.
None of this is unusual. It is, in fact, typical. And it means the organization is carrying significant operational and security risk in infrastructure that nobody owns, nobody reviews, and nobody has tested recovering from a failure.
Cloud PKI eliminates most of that operational burden. The provider manages the underlying infrastructure, handles availability, and maintains the service. You configure certificate profiles and policies; they handle the rest.
Modern device management requires cloud PKI
If your endpoint management strategy has shifted to Microsoft Intune — managing Entra-joined devices, BYOD, or remote workers who are never on the corporate network — AD CS creates a fundamental problem. Domain-joined auto-enrollment via GPO only works for devices that are on the domain. Intune-managed devices that are Entra-joined (not hybrid-joined) cannot reach an on-premises CA for SCEP or PKCS certificate issuance without a Network Device Enrollment Service (NDES) proxy or equivalent.
That proxy adds complexity, becomes a single point of failure, and requires ongoing maintenance. Microsoft Cloud PKI, by contrast, is natively integrated with Intune — no proxy, no on-premises dependency, no VPN requirement. For organizations moving toward a cloud-first or zero-trust endpoint posture, this is a significant architectural simplification.
Certificate lifecycle visibility
One of the most common failure patterns in enterprise environments is the unexpected certificate expiration — a server goes down, a Wi-Fi authentication policy stops working, an internal application throws TLS errors. AD CS does not provide enterprise-wide certificate visibility out of the box. You need additional tooling (or manual PowerShell scripting) to build a picture of what certificates have been issued, to what, and when they expire.
Modern cloud PKI platforms are built around visibility as a core feature. Certificate inventory, expiry alerting, and revocation management are first-class capabilities rather than afterthoughts.
Talent and knowledge transfer
AD CS expertise is narrowing. The pool of engineers who deeply understand certificate templates, OID structures, CDP and AIA extensions, and HSM integration is smaller than it was ten years ago and getting smaller. Cloud PKI services abstract away most of that complexity, which means more engineers on your team can own and operate the infrastructure without specialized PKI training.
The Middle Path: Hybrid PKI
For most organizations, the answer is not a binary choice. A practical approach that is gaining traction:
Keep the root CA on-premises, offline, and air-gapped. The root CA is the trust anchor for your entire PKI. It should be rarely used (only to sign issuing CA certificates), stored offline, and protected with the highest level of physical and cryptographic control your organization can provide. This part of the infrastructure rarely changes and benefits from the control that on-premises ownership provides.
Move issuing CA functions to the cloud. Microsoft Cloud PKI supports Bring Your Own CA (BYOCA) — you can subordinate a cloud issuing CA to your existing on-premises root, preserving your trust chain while offloading the operational complexity of certificate issuance and lifecycle management to a managed service.
Use cloud PKI for Intune-managed endpoints, AD CS for domain-joined legacy workloads. Run both in parallel during transition, with a defined roadmap for retiring the on-premises issuing CA as domain-joined workloads migrate to Entra join.
A Framework for the Decision
| Factor | Favor AD CS | Favor Cloud PKI |
|---|---|---|
| Endpoint management | Primarily domain-joined via GPO | Intune-managed, Entra-joined, or BYOD |
| Network model | On-premises or hybrid | Cloud-first, zero-trust, remote-heavy |
| Compliance / key custody | Strict HSM and key control requirements | Standard enterprise compliance posture, AKV HSM backed |
| Air-gap requirements | Present (OT, classified, critical infra) | Not applicable |
| PKI operational maturity | Well-documented, actively maintained | Undocumented, aging, no clear owner |
| Team expertise | AD CS skills in-house | Generalist team, cloud-native preference |
| Legacy app dependencies | Significant (Kerberos PKINIT, S/MIME), Data at rest encryption, contract signing | Minimal or already migrated, Authentication only |
AD PKI is not legacy technology that needs to be replaced on principle but we would like to reduce the dependency on it as we like to minimize or remove AD. In the right environment — hybrid, well-maintained, with genuine on-premises requirements — it is still the right answer. The problem is not the technology; it is the organizational reality that most AD CS deployments are not well-maintained, and the expertise to maintain them correctly is becoming harder to find and retain.
A Cloud-based PKI (SCEPman, Intune Cloud PKI, ...) is not a silver bullet. It introduces its own dependencies, its own vendor relationships, and its own constraints. But for organizations moving toward cloud-first endpoint management, a zero-trust network model, or simply trying to reduce the operational debt carried by aging infrastructure, it removes a category of complexity that has historically been a source of quiet, chronic risk.
The question worth asking is not "which is better?" It is: what does our PKI actually look like today, who owns it, and what would happen if we had to rebuild it from scratch tomorrow?
If you can answer all three confidently — keep what you have and invest in improving it. If you cannot — that is the case for change.
The Hidden Cost of a Username Change
There's a change request that looks routine on the surface. An employee gets married. A legal name change comes through HR. A company completes a domain consolidation after an acquisition. Someone just wants their email to finally match their preferred name.
The ticket says: Update UPN from jsmith@frontoso.com to john.smith@frontoso.com.
To the helpdesk, it looks like a two-minute task. To the identity engineer who understands what that UPN touches, it looks like a change management project.
I've been cataloguing the UPN change behavior of over 65 SaaS applications — everything from Microsoft 365 workloads to physical access control systems — and the pattern I keep seeing is the same: the identity change is easy. The downstream consequences are not.
Why a UPN Change Is Never Just a UPN Change
In a modern enterprise, the User Principal Name is not just a login credential. It is the primary key that dozens of systems use to identify, provision, and authorize a user. Change it in one place, and you have not changed it everywhere — you have created a mismatch that each system will resolve in its own way.
Some systems handle it gracefully. They anchor user identity to an immutable internal object ID, accept the UPN change via SCIM, and update their records without any service disruption. These are the well-architected ones.
Others use the UPN or email address as the primary key in their user store. Change the UPN upstream, and the next time that user tries to log in, the application does not recognize them. It creates a new account. The old account — with its permissions, its content, its history — sits orphaned.
And then there is a third category that is in some ways the most dangerous: applications where the UPN change succeeds silently, but a downstream business process quietly stops working. Approval workflows that route to the old email. Certificates that still carry the old UPN in the Subject Alternative Name. SIP addresses that were set at provisioning time and never updated.
The user can log in. Everything appears fine. And then three weeks later someone asks why their Oracle approval workflow notifications stopped arriving, or why their Wi-Fi drops every time their device certificate is checked.
The Failure Modes, Categorized
After testing and documenting 65 applications, the failure modes cluster into a few distinct patterns.
1. The Duplicate Account Problem
This is the most common failure mode for applications that use JIT (Just-In-Time) provisioning. JIT creates a user account on first login by matching the incoming SAML assertion to an existing record — or creating a new one if no match is found. If the UPN changes, the assertion no longer matches, and a new account is created.
The old account is not deleted. It just sits there, with all of its permissions and content, attached to an identity the user can no longer access. Examples: Zendesk, ArcGIS Online, Cisco Webex (if SCIM attribute mapping is misconfigured), SendGrid.
ArcGIS Online is a particularly painful case. The internal username is derived from the SAML NameID at first login and is immutable after that. A UPN change means a new ArcGIS account. All content, group memberships, and licenses on the old account must be manually migrated — there is no automated path.
2. The Silent Business Process Failure
These applications can survive a UPN change without breaking authentication — but something downstream stops working in a way that is not immediately obvious.
Oracle Fusion ERP is the clearest example in my research. Oracle approval workflows send notification emails using the email address stored in the Oracle user record. If that email address does not match the user's actual primary email after a UPN change, approval notifications route to a dead address. Approvals time out. Business processes stall. Nobody gets an error message — the workflow just stops producing results.
Microsoft Teams has a similar pattern. The Teams identity survives the UPN change because it is anchored to the Entra ID objectId. But the SIP address — which was provisioned from the UPN at the time the Teams account was created — does not automatically update. Federated calls still route to the old SIP address. The user's outbound SIP identity mismatches. External meeting invites show the old address. This requires a manual PowerShell operation to correct: Set-CsUser -Identity <newUPN> -SipAddress sip:<newUPN>.
Microsoft Intune surfaces the most technically subtle failure. Device enrollment and policy sync survive the UPN change cleanly — Intune uses objectId as the anchor. But SCEP and PKCS certificates issued to enrolled devices contain the old UPN in the Subject Alternative Name field. Those certificates remain valid until expiry. Applications that validate the SAN against the current Entra UPN — Wi-Fi using EAP-TLS, VPN with certificate authentication — will fail after the UPN change because the certificate no longer matches the identity. New certificates are issued on the next policy sync cycle, but the window between UPN change and certificate renewal is a silent authentication failure waiting to happen.
3. The MFA Device Orphan Problem
Duo Security deserves its own category. Duo identifies users by username — not by an immutable object ID. If the UPN is used as the Duo username (which is the default configuration with Entra ID directory sync), a UPN change causes Duo to create a new user record and mark the old one for deletion. Enrolled MFA devices — phones, hardware tokens — do not transfer automatically. The user must re-enroll every device on the new username.
For most applications this is inconvenient. For healthcare organizations using Duo with Epic for EPCS (electronic prescribing of controlled substances), it is a compliance-critical workflow failure. Duo sends the UPN as the identity claim to Epic by default. A UPN change without a coordinated Duo update breaks e-prescribing until the Duo record is corrected.
The mitigation requires specific sequencing: add the new UPN as a username alias on the existing Duo record before the UPN change syncs. This preserves the device enrollment through the transition. Then update the primary username after sync completes. Most organizations discover this only after the first failure.
4. The Consent and Access Grant Problem
Quest OnDemand Migration is an example of a category that is easy to overlook: tooling platforms where the impacted accounts are administrators and operators, not end users.
Quest OnDemand identifies administrators by UPN via Microsoft OAuth. A UPN change for the subscription owner breaks portal access entirely — Quest support must be involved to correct backend records. All per-workload OAuth consents (Exchange, Teams, SharePoint) are tied to the consenting admin's UPN and become orphaned on change. The mitigation is strict: add the new UPN to the OnDemand org RBAC and re-grant all consents before deactivating the old identity.
A Reference Table: How Common SaaS Applications Handle It
The following table summarizes the UPN change behavior of a selection of applications from our full 65-app research set. The full dataset — including SCIM availability, stable ID anchor, JIT risk rating, admin steps, and test cases — is available as a companion spreadsheet.
| Application | Support Level | Key Risk |
|---|---|---|
| Microsoft 365 / Entra ID | ✅ Full | Downstream app friction; verify SCIM matching uses objectId |
| Salesforce | ✅ Full | SCIM 2.0; internal SF User ID is stable anchor |
| Slack | ✅ Full | Member ID is stable; email propagates via SCIM |
| AWS IAM Identity Center | ✅ Full | Map objectId to SCIM externalId for stable anchor |
| Asana | ✅ Full | Business+ plan required for SCIM |
| SharePoint / OneDrive | ⚠️ Partial | OneDrive URL changes; all shared links break; user must re-share |
| Microsoft Teams | ⚠️ Partial | SIP address does not auto-update; manual PowerShell required |
| Exchange Online | ⚠️ Partial | Primary SMTP may not update; old address retained as alias |
| Microsoft Intune | ⚠️ Partial | SCEP/PKCS cert SAN contains old UPN; Wi-Fi/VPN auth fails until renewed |
| Atlassian (Jira/Confluence) | ⚠️ Partial | Default SCIM matching uses UPN not objectId — must reconfigure |
| GitHub Enterprise | ⚠️ Partial | Admin-only change; SAML re-link required; CODEOWNERS breaks |
| Cisco Webex | ⚠️ Partial | UPN mismatch creates new account; old user goes Inactive (30-day soft delete) |
| SAP Concur | ⚠️ Partial | Entra gallery connector deprecated/broken; route via SAP Cloud Identity Services |
| Duo Security | ⚠️ Partial | New Duo user created; enrolled devices orphaned; add alias BEFORE change |
| Oracle Fusion ERP | ⚠️ Partial | Email mismatch breaks approval workflow routing |
| Figma | ⚠️ Partial | UPN/SCIM mismatch = stuck 'Pending SCIM' state |
| KnowBe4 | ⚠️ Partial | SCIM source attribute must match SSO NameID — update both consistently |
| 8x8 | ⚠️ Partial | Federation ID update on CREATE only — manual admin update required after change |
| ArcGIS Online | ❌ None | Internal username is immutable; UPN change = new account; old content orphaned |
| Zendesk | ❌ None | Email-keyed; UPN change via JIT creates new account |
| SentinelOne | ❌ None | Email cannot be changed via API; deactivate and recreate required |
| Epic (Hyperspace) | ❌ None | No SCIM; Hyperspace analyst must update; Duo EPCS breaks separately |
| Lenel OnGuard | ❌ None | On-premises PACS; manual operator record update; no SCIM |
| SendGrid | ❌ None | No native SCIM; JIT creates new account on mismatch |
What Good Looks Like
The applications that handle UPN changes well share a common design principle: they separate identity from addressing. The user is identified internally by an immutable object ID — Slack's Member ID, Salesforce's User ID, Entra's objectId. The UPN or email address is just an attribute on that object, and attributes can be updated without disrupting the identity relationship.
Applications that fail at this use the UPN or email as the primary key. The address is the identity. Change the address and you have created a new identity — which means a new account, orphaned content, and lost history.
SCIM 2.0 is the mechanism that makes clean UPN changes possible — but only when it is configured correctly. The most common misconfiguration is using UPN as the SCIM matching attribute instead of objectId. Atlassian's default configuration still does this. It is the first thing I check in any environment before approving a bulk UPN change.
Before You Touch That UPN
If there is one operational takeaway from this research, it is this: a UPN change requires an application audit before it can be treated as routine.
The questions I ask before any UPN change in a client environment:
- Which applications does this user access?
- Of those, which use JIT provisioning with email as the primary key?
- Which have business process workflows that route notifications by email?
- Which issue certificates or tokens that embed the UPN?
- Which have MFA enrollments tied to the current username?
- Which have admin or operator access where the UPN is used for consent grants?
The answers to those questions determine whether a UPN change is a two-minute ticket or a coordinated multi-system change management event.
The two-minute assumption is how things break quietly.