Phishing-Resistant Authentication

The security goal is simple: eliminate password-based phishing as an attack vector. How you get there depends on your environment—not every workplace can use a camera, a fingerprint reader, or a USB port.

This section covers three paths to the same destination. All three authenticate against Microsoft Entra ID in the cloud. All three satisfy CMMC IA.L2-3.5.3 and NIST AAL2. The hardware is what differs.

Choosing the Right Path

Your Environment	Recommended Path
Standard office: cameras and USB work fine	Path 1 — Windows Hello for Business
Harsh environment (oil mist, dust, moisture): cameras and USB unreliable; existing PKI	Path 2 — PIV Cards with Entra CBA
Harsh environment; no PKI and no desire to build one	Path 3 — FIDO2 NFC Security Keys

The key insight: all three paths terminate at Entra ID. You are not choosing between "cloud" and "on-prem." You are choosing the hardware token that fits your workplace.

Path 1: Windows Hello for Business — The Easy Button

Windows Hello for Business (WHfB) is the default recommendation for any environment where standard hardware is usable. There is no PKI to manage, no cards to issue, and no readers to deploy. A biometric gesture or PIN, backed by a hardware TPM, replaces the password entirely.

Cloud Kerberos Trust Deployment Model

For cloud users, use fully Intune-managed machines configured with Windows Hello for Business with Cloud Kerberos Trust. It offers the best balance of user experience (fast login, seamless SSO) and IT overhead (no AD FS, no user certificate management).

For pure on-premises users, while security baselines can be managed by Microsoft Defender for Endpoint (MDE), MDE does not handle identity enrollment. Deploying Windows Hello for Business for these users requires an On-Premises deployment model (either Key Trust or Certificate Trust). Because they cannot reach Entra ID, this forces you to build an AD FS farm to act as the device registration authority and rely on Group Policy (GPO) to push the enrollment policies.

While Key Trust is a viable fallback here, it is functionally deprecated in favor of Cloud Kerberos Trust for modern deployments. Cert Trust should be avoided entirely unless you are strictly forced by legacy non-Windows infrastructure (such as older 802.1x RADIUS/NAC appliances or legacy VPN gateways that strictly require X.509 client certificates).

Hardware Assumptions

Infrastructure: Windows Server 2016+ Domain Controllers (2019/2022 recommended).

Endpoints: Windows 11 Enterprise with TPM 2.0.

How Cloud Kerberos Trust SSO Works

Smart Card (legacy): Client presents X.509 Cert → DC validates Cert → DC issues Kerberos TGT.
Cloud Kerberos Trust:
1. User logs in to Windows (biometric or PIN).
2. Windows authenticates to Entra ID and receives a Cloud TGT (partial ticket).
3. Windows presents this Cloud TGT to the local Domain Controller.
4. The DC (using a local AzureADKerberos computer object) validates it and issues a standard On-Prem TGT.
5. Result: The user opens \\server\share just like with a Smart Card—but never touched a certificate.

WHfB Deployment Model Comparison

Feature	Cloud Kerberos Trust (Recommended)	Key Trust (Fallback)	Cert Trust (Avoid)
User Experience	Best. Login is instant.	Good. Initial setup waits up to 30 min for key sync.	Poor. Slow cert validation; CRL failures.
IT Overhead	Lowest. No PKI on endpoints. No AD FS. 100% Intune.	Medium. PKI for DCs. Key sync to AD user objects.	Highest. NDES/SCEP for every device.
CMMC Compliance	High. FIPS 140-validated. Phishing-Resistant MFA flag.	High. FIPS 140-validated.	High, but complexity breeds misconfiguration.
Network Requirements	Light. Client → Internet only. DC stays intranet.	Heavy. DC → Internet for CRL checks.	Heavy. Client → NDES (intranet).

Network & Firewall Impact

For Cloud Kerberos Trust, your Domain Controllers do not require outbound Internet access.

Client (user device): Port 443 to Entra ID.
Domain Controller: Standard RPC/LDAP from the client. Does not talk to Azure.
Entra Connect Server: Port 443 to Entra ID to sync the AzureADKerberos object one time.

The AzureADKerberos computer object is created in AD by Entra Connect. DCs use this local object to validate cloud tickets, keeping them air-gapped from the internet.

Checklist

Infrastructure: Verify DCs are Windows Server 2016+ (2022 recommended).
Policy: Enable Cloud Kerberos Trust via Intune policy or GPO.
PKI: Retain for privileged admins; deprecate for standard users.

Path 2: PIV Cards with Entra Certificate-Based Authentication — Harsh Environments

Some workplaces make WHfB impractical: oil mist fogs cameras, moisture defeats fingerprint readers, and airborne contaminants clog USB ports. In these environments, an NFC PIV card is the right form factor—and Entra Certificate-Based Authentication (CBA) is the cloud-native mechanism that makes it work without an AD FS server.

This is still cloud-first

Entra CBA is a cloud feature (generally available since 2022). Your PKI may live on-prem, but authentication happens against Entra ID. You are not building a parallel on-prem auth stack.

How It Works

User taps NFC PIV card on reader
    → Windows presents the card's X.509 certificate to Entra ID
    → Entra ID validates the certificate against trusted CA roots uploaded to Entra
    → Entra issues a token
    → User is signed in (Entra ID, M365, cloud resources)

No AD FS. No on-prem proxy. The NFC reader appears to Windows as a standard smart card reader, so the existing Windows smart card stack handles everything below the Entra authentication layer.

What You Need

Hardware:

NFC PIV-compliant cards (e.g., HID Crescendo, Yubico YubiKey 5 NFC in PIV mode, Identiv uTrust)
NFC smart card readers (e.g., HID OMNIKEY 5022, ACS ACR1252U)—sealed or ruggedized models are available for harsh environments

PKI requirements:

An existing Certificate Authority (on-prem is fine)
End-entity certificates issued to users, with the user's Entra UPN in the Subject Alternative Name (SAN)
CRL Distribution Points (CDPs) that Entra can reach—either internet-accessible or published via a reverse proxy

Entra configuration:

Step 1 — Enable Certificate-Based Authentication

Navigate to Entra Admin Center → Protection → Authentication methods → Certificate-based authentication. Set the policy to Enabled and scope it to All users or a pilot group.

Step 2 — Upload your CA certificate chain

In the same blade, open the PKI tab and click + Add. For each certificate in your chain (root first, then any intermediaries):

Field	Value
Certificate Authority	Upload the `.cer` or `.crt` file (DER or PEM format)
OCSP Responder URL	Enter if you have one; leave blank if using CRL only
CRL Distribution URL	Paste the HTTP URL from your CDP (must be internet-accessible)
Certificate Revocation	Set to Online (Entra will check the CRL at authentication time)
CA Type	Root for the root CA; Intermediate for any subordinate CAs

Repeat for each CA in the chain. Entra will not trust end-entity certificates unless the complete chain back to a trusted root is uploaded here.

CRL URL must be HTTP, not HTTPS

Entra CBA fetches CRLs over plain HTTP (per RFC 5280). Your CDP URL must begin with http://, even in GCC High. The content is signed by the CA, so integrity is preserved without TLS.

Step 3 — Configure Authentication Binding (what strength does a cert grant?)

In the Authentication binding tab, set the Default protection level to Multi-factor authentication. This is the fallback for any certificate that doesn't match a more specific rule.

To be more precise—for example, to grant MFA strength only to certificates issued by your PIV card CA and single-factor to all others—add a rule:

Click + Add rule
Set Certificate field to Issuer (or Policy OID if your CA embeds an id-piv-Auth OID)
Enter the issuer DN or OID value for your PIV card CA
Set Protection level to Multi-factor authentication
Set the rule Priority to 1 (lower number = higher priority)

Use Policy OID for the cleanest rule

PIV cards typically embed the id-piv-Authentication OID (2.16.840.1.101.3.6.7) in the certificate policy extension. Binding on this OID rather than the issuer DN is more specific and survives CA rekeying without rule changes.

Step 4 — Configure Username Binding (how does Entra find the user?)

In the Username binding tab, define how Entra maps the certificate to an Entra user account. Add a binding:

Field	Typical Value
Certificate field	`PrincipalName` (SAN UPN)
Attribute	`userPrincipalName`
Priority	`1`

If your certificates carry the user's email in RFC822Name instead of a UPN in PrincipalName, map RFC822Name → mail instead. Add a second lower-priority rule as a fallback if needed.

GCC High UPN suffix

In GCC High, user UPNs end in .onmicrosoft.us. Ensure the SAN UPN in the issued PIV certificates matches the user's Entra UPN exactly—including the suffix. A mismatch here is the most common cause of binding failures at login.

Step 5 — Enforce CBA via Conditional Access

Creating the CBA configuration above does not automatically require users to use it. You must enforce it through Conditional Access.

Option A — Use a built-in authentication strength:

Navigate to Entra Admin Center → Protection → Conditional Access → Authentication strengths
Select the built-in Phishing-resistant MFA strength (includes CBA and FIDO2; excludes TOTP/SMS)
Create or modify a CA policy: Users = PIV card users group, Conditions as needed, Grant = Require authentication strength → Phishing-resistant MFA

Option B — Create a custom authentication strength (recommended if you want CBA-only):

Click + New authentication strength
Name it (e.g., PIV Card - CBA Only)
Check Certificate-based authentication (Multi-factor) only
Reference this custom strength in your CA policy grant control

With Option B, users in the scoped group cannot satisfy the policy with FIDO2 or Microsoft Authenticator—only a PIV cert will pass. This is appropriate if your environment mandates PIV specifically.

CRL Accessibility: The One On-Prem Consideration

Entra CBA performs CRL checks when validating certificates. Your CDP URLs (embedded in issued certificates) must resolve to an accessible endpoint. Options:

Publish the CRL to a public URL (e.g., via Azure Blob Storage or a DMZ web server)
Use an OCSP responder with a public endpoint
This is the one infrastructure piece that must be reachable from the internet—but it is read-only and stateless

PKI Operational Overhead

If you already have a PKI, the additional work is:

Upload CA certs to Entra (one-time)
Issue certificates to PIV cards (ongoing, like any smart card program)
Configure Conditional Access (one-time)

If you do not have a PKI, building one is a significant investment. In that case, evaluate Path 3 first.

Checklist

Hardware: Procure NFC PIV cards and ruggedized NFC readers for affected workstations.
PKI: Confirm CDP endpoints are internet-accessible. Issue user certificates with UPN in SAN.
Entra: Upload CA certificates. Configure certificate binding rules. Enable Entra CBA.
Conditional Access: Require phishing-resistant authentication strength for affected users or locations.
Test: Sign in with a PIV card on an NFC reader before rollout.

Path 3: FIDO2 NFC Security Keys — Harsh Environments Without PKI

If you need NFC form factor but don't have (and don't want to build) a PKI, FIDO2 security keys with NFC deliver the same phishing-resistant posture without certificates.

Examples: YubiKey 5 NFC, YubiKey 5C NFC, HID Crescendo Key. These are tapped against an NFC reader or plugged in via USB—but in a harsh environment, the NFC capability is what matters.

How It Works

User taps FIDO2 NFC key on reader
    → Windows passes the FIDO2 assertion to Entra ID
    → Entra validates the cryptographic challenge response
    → Entra issues a token
    → User is signed in

No PKI. No certificates. No CRL infrastructure. Entra handles everything natively.

Tradeoffs vs. PIV

	FIDO2 NFC Key	PIV Card + Entra CBA
PKI required	No	Yes
Card management (issuance, revocation)	Key lifecycle only	Full certificate lifecycle
CMMC/NIST compliance	AAL2 phishing-resistant	AAL2/AAL3 phishing-resistant
Form factor	Key fob (NFC or USB)	Credit-card sized (NFC)
Best when	No existing PKI; simpler rollout	Existing PKI; regulatory requirement for PIV/CAC

note

If your environment or contract specifically requires PIV/CAC (common in DoD supply chain work), Path 2 is mandatory. FIDO2 keys, while phishing-resistant, are not PIV-compliant.

PKI Transition Strategy

If you are migrating from a smart card program to WHfB (Path 1), the question is always: do we throw away the PKI?

No. You transition it from "daily driver" to "break glass."

Coexistence: Smart cards and WHfB coexist at the Windows lock screen. A user can tap a card or use their WHfB gesture.
The shift: Stop issuing smart cards to standard users. Reserve them for Tier 0 privileged admins and break glass accounts.
Timeline: Run both in parallel until WHfB enrollment exceeds 95%, then deprecate card issuance for standard users.

If you are on Path 2 (PIV + Entra CBA), your PKI remains the daily driver. The transition is from ADFS-mediated authentication to Entra CBA—not from PKI to no-PKI.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.