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.