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 four phishing-resistant paths. All four authenticate against Microsoft Entra ID in the cloud. All four satisfy phishing-resistant MFA at NIST SP 800-63B AAL2 and are the strongly recommended approach for any environment handling CUI or sensitive data.

If phishing-resistant authentication is not operationally feasible, Microsoft Authenticator push notifications satisfy the baseline MFA requirement but are susceptible to MFA fatigue (push bombing) and real-time adversary-in-the-middle attacks. See the note at the bottom of the path selection table.

GCC High / CMMC
Commercial / NIST

CMMC IA.L2-3.5.3 — Multi-Factor Authentication: Employ multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. The four phishing-resistant paths in this section each satisfy this control and are strongly recommended. Standard Authenticator push notifications satisfy the baseline MFA requirement in IA.L2-3.5.3 but are not phishing-resistant — C3PAOs will scrutinize this choice and it should be documented and justified in your SSP.

Choosing the Right Path

Your Environment	Recommended Path
Standard office: cameras, fingerprint readers, and USB work fine	Path 1 — Windows Hello for Business
Standard office: phone-based auth preferred (BYOD users, contractors, or devices without TPM 2.0)	Path 2 — Microsoft Authenticator with Passkey
Harsh environment; no PKI and no desire to build one	Path 3 — FIDO2 NFC Security Keys
Pure AVD enclave: users have no corporate local device; all work happens through a remote session	Path 3 — FIDO2 NFC Security Keys
Harsh environment (oil mist, dust, moisture): cameras and USB unreliable; existing PKI	Path 4 — PIV Cards with Entra CBA
DoD supply chain contract specifically requiring PIV/CAC	Path 4 — PIV Cards with Entra CBA
Phishing-resistant authentication not operationally feasible (baseline MFA only — see warning below)	Microsoft Authenticator — push notifications

Standard push notifications are not phishing-resistant

Microsoft Authenticator push notifications satisfy the baseline multi-factor authentication requirement — a second factor is required — but are not phishing-resistant. They are susceptible to MFA fatigue attacks (push bombing) and real-time adversary-in-the-middle phishing, where an attacker captures a valid session token after the user approves a fraudulent push request.

For GCC High environments pursuing CMMC Level 2, phishing-resistant MFA is the strongly recommended standard. Standard push is a conscious trade-off: document the decision, the risk acceptance rationale, and compensating controls (number matching, additional context, Conditional Access sign-in frequency) in your System Security Plan.

The key insight: all four phishing-resistant paths terminate at Entra ID. You are not choosing between "cloud" and "on-prem." You are choosing the authenticator that fits your workforce.

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.

WHfB satisfies MFA at the Windows logon screen

When a user signs in with WHfB (PIN or biometric), Windows performs a cryptographic authentication against Entra ID and receives a Primary Refresh Token (PRT) carrying a phishing-resistant MFA claim. That PRT is silently reused by every app the user opens — including background services like the Intune enrollment scheduled task on Hybrid Joined machines.

This means WHfB is not simply a credential that leads to MFA — it is the MFA event at sign-in. Clients with a compliance requirement for "phishing-resistant MFA to the desktop" satisfy that requirement through WHfB directly, with no additional authentication step required.

References: Is Windows Hello for Business MFA? · NIST SP 800-63B §5.1.9 (Multi-Factor Cryptographic Device) · OMB M-22-09: Phishing-Resistant MFA

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.
Compliance Posture	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: Windows Hello for Business

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: Microsoft Authenticator with Passkey — BYOD and Soft-Token Environments

Microsoft Authenticator supports device-bound passkeys — FIDO2 credentials stored in the Authenticator app on a user's iOS or Android phone. This is the lowest-friction path after WHfB: most users already have Authenticator installed for Entra MFA, and passkey registration is self-service through MySignIns. No hardware to ship, no PKI, no card readers.

Passkeys in Authenticator are phishing-resistant by design: the credential is cryptographically bound to the specific Entra tenant, so an authentication response cannot be replayed against a spoofed sign-in page.

When to choose Path 2 over Path 1

Choose Authenticator passkeys when the user's primary access path is a browser or a device without WHfB capability — such as personal BYOD devices, contractor-issued machines, or any scenario where provisioning a Windows Hello credential on the local device is not feasible. Users who have WHfB provisioned on their corporate Windows device should continue using WHfB (Path 1). Both methods can coexist on the same Entra account.

Prerequisites

Authenticator app: Microsoft Authenticator version 6.2406.7535 or later on iOS 16+ or Android 9+.
Entra license: No additional license beyond M365 E3/G3 or F3.
Authentication Methods policy: Passkeys (FIDO2) enabled in Entra with Microsoft Authenticator allowed.

Enable Passkeys in Entra

Navigate to Entra Admin Center → Protection → Authentication methods → Passkeys (FIDO2).

Setting	Value
Enable	Yes
Target	All users or a scoped group
Self-service setup	Allowed
Key restrictions	Disabled (allows all FIDO2 authenticators), or restrict to Microsoft Authenticator's AAGUID if Authenticator-only is required

To restrict passkey registration to Microsoft Authenticator only — excluding hardware FIDO2 keys from this policy — enable Key restrictions and add Microsoft Authenticator's AAGUID. Microsoft publishes current AAGUID values in the Entra passkeys documentation. Users can still sign in with hardware FIDO2 keys if those keys were registered separately under an unrestricted policy.

User Registration (Self-Service)

Users register through MySignIns. The experience is consistent across all Entra tenants.

Step 1 — Open Security Info

Navigate to https://mysignins.microsoft.com/security-info and sign in.

Step 2 — Add a passkey

Click + Add sign-in method → select Passkey in Microsoft Authenticator.

Step 3 — Complete the pairing

The browser displays a QR code or a direct link:

Open Microsoft Authenticator on the mobile device.
Tap the passkey prompt or scan the QR code.
Approve with biometric (Face ID, Touch ID, or device PIN) to confirm identity.
The passkey is created and tied to the user's Entra account.

Step 4 — Name and confirm

Name the passkey descriptively (e.g., iPhone 15 - Authenticator). Verify it appears in the Security Info list.

At any Entra sign-in page:

Enter the username.
Select Sign in with passkey (or the passkey prompt appears automatically in supported browsers).
A push notification appears in Microsoft Authenticator.
The user approves with biometric or device PIN.
Sign-in completes — phishing-resistant MFA satisfied.

The response is cryptographically bound to the exact sign-in challenge; it cannot be reused or redirected.

Tradeoffs

	Authenticator Passkey (Path 2)	WHfB (Path 1)	FIDO2 Hardware Key (Path 3)
Hardware required	User's own phone	Corporate Windows device with TPM 2.0	FIDO2 key (YubiKey, etc.)
Provisioning	Self-service via MySignIns	Intune or GPO policy	Self-service via MySignIns
MFA at Windows logon	No — cloud apps and browser only	Yes — PRT from Windows logon carries MFA claim	No (unless configured for Windows sign-in separately)
Works inside an AVD session	Yes	Not for provisioning; already-provisioned WHfB works for connecting to AVD	Yes
Phone dependency	Yes — phone must be available	No	No

Authenticator passkeys do not replace WHfB for Windows logon

A passkey in Authenticator authenticates against cloud apps and browser sign-ins — it does not replace the Windows logon credential. A user signing in to a corporate Windows device with an Authenticator passkey still logs in to Windows with a password or PIN. WHfB (Path 1) is the mechanism that eliminates the Windows password and mints a phishing-resistant PRT at logon. For environments where MFA at the Windows desktop is a compliance requirement, Path 1 or Path 3 are the appropriate choices.

Checklist: Authenticator Passkey

Enable Passkeys (FIDO2) in Entra Authentication Methods scoped to the target group.
Verify Authenticator app version meets the minimum on user devices.
Communicate the MySignIns self-service registration URL before enforcing any CA policy.
Confirm registration via Entra → Users → [user] → Authentication methods before switching policies from Report-Only to Enforced.
Conditional Access: Reference the built-in Phishing-resistant MFA authentication strength — Authenticator passkeys satisfy this strength.

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: FIDO2 NFC Keys

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
Compliance posture	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

Registering a FIDO2 Key — Workflow for AVD-Only Users

Windows Hello for Business cannot be provisioned from inside a remote session (see WHfB Setup). Users whose only access path is through AVD must register a FIDO2 security key before their first sign-in if the A002 phishing-resistant CA policy is enforced.

Registration happens through a browser and does not require a managed device. Users can register from any PC, including a personal machine.

Step 1 — Navigate to Security Info

Open a browser and go to https://mysignins.microsoft.com/security-info. Sign in with the user's Entra credentials (password + existing MFA if already registered).

Step 2 — Add the Security Key

Click + Add sign-in method → select Security key → select USB device (works for both USB and NFC keys).

Follow the browser prompts:

When asked to insert the key, plug it in (or tap it on the NFC reader if using an NFC key with a compatible reader attached)
Touch the gold contact or button when the key blinks — this is the user presence check
Set a PIN for the key if prompted (required for FIDO2 PIN-backed credentials)
Name the key (e.g., YubiKey - Primary)

The key is now registered as a credential on the user's Entra account.

Step 3 — Verify the Auth Strength

After registration, confirm the key satisfies the A002 policy. In the Entra Admin Center, navigate to Users → [user] → Authentication methods and verify the security key appears and is listed as phishing-resistant.

Step 4 — First AVD Sign-In

When the user connects to AVD (via https://client.wvd.microsoft.us in GCC High or https://client.wvd.microsoft.com in Commercial, or the Remote Desktop client):

Enter the username and select Sign in with a security key
Insert or tap the FIDO2 key and touch the contact when prompted
The sign-in satisfies the A002 phishing-resistant auth strength and the P006 compliant-device policy (the AVD session host is the compliant device, not the user's local machine)

If A002 (Require Phishing-Resistant Auth) is enforced and a user has not pre-registered a FIDO2 key or other phishing-resistant method, they will be blocked at sign-in with no actionable error message. Verify all users have a registered method in Entra > Users > Authentication methods before switching A002 from Report-Only to Enforced. See AVD Deployment Timeline — Phase 2 for the recommended pre-enrollment step in the deployment sequence.

note

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

Path 4: PIV Cards + Entra Cert-Based Auth — 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: PIV / CBA

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
Commercial

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.

No corresponding requirement for Commercial tenants — standard .onmicrosoft.com UPN suffixes are used and certificate SAN matching follows the same logic without sovereign-suffix considerations.

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.

Expert Implementation: Phishing-Resistant Authentication

Rolling out Entra Certificate-Based Authentication (CBA) or FIDO2 keys without locking out your workforce requires precise Conditional Access staging. If your environment requires complex PKI integrations or you need help transitioning from legacy smart cards to a modern, cloud-first identity posture, the team at Mindline specializes in these exact deployments. Reach out at mindline.com to schedule an identity architecture review.

This is where PIV + Entra CBA diverges from what most administrators expect. On a traditional AD-joined machine, smart card logon routes through a domain controller. On an Entra Joined machine, the path is entirely different — and understanding the difference prevents a category of login failures that produce no useful error message.

Step-by-step at the lock screen

The NFC reader presents the card to Windows as a standard smart card.
The Windows Smart Card credential provider activates and displays the card as a logon option on the lock screen.
Windows prompts for the card's PIV PIN — not the user's Windows password or Entra password. The PIN unlocks the card's private key.
Windows passes the certificate and the private key operation to the Web Account Manager (WAM), which routes the authentication request to Entra ID — not to a domain controller.
Entra validates the certificate against the uploaded CA chain, performs the CRL check, evaluates the binding rules, and issues a Primary Refresh Token (PRT).
Windows uses the PRT to complete sign-in. The user sees their desktop.

Tap card
    → Smart Card credential provider activates
    → PIN prompt (PIV card PIN — unlocks private key)
    → WAM routes certificate to Entra CBA (not to a DC)
    → Entra validates cert, CRL, and binding rules
    → PRT issued
    → Windows desktop

No Kerberos TGT. No domain controller in the path. The PRT is the session credential from this point forward, used to obtain tokens for M365 and other Entra-protected resources silently.

Traditional smart card logon vs. Entra CBA

	Traditional Smart Card (AD-joined)	PIV + Entra CBA (Entra Joined)
After PIN entry	Certificate → Domain Controller	Certificate → WAM → Entra ID
Credential issued	Kerberos TGT	Primary Refresh Token (PRT)
DC required	Yes	No
On-prem file share access	Native (Kerberos)	Via Entra token or separate Kerberos path

If your devices are Entra Joined (cloud-only path), there is no DC for the card to talk to — and none is needed.

CA trust prerequisite on the device

The Windows Smart Card credential provider will only surface a card at the login screen if Windows trusts the certificate's issuing CA. If the CA is not in the device's Trusted Root Certification Authorities store, the card is treated as unknown and does not appear as a logon option — with no error message to the user.

Deploy the CA certificate chain to devices via Intune before users attempt PIV logon:

Navigate to Intune → Devices → Configuration → + Create policy
Platform: Windows 10 and later / Profile type: Trusted certificate
Upload the root CA certificate; repeat for any intermediate CAs
Assign to the device group containing PIV workstations

If the CA is not trusted, the card tile simply does not appear

A user whose workstation is missing the issuing CA in its trusted root store will see only the standard PIN/password credential options at the lock screen. The PIV card tile will not appear, there is no error, and no event log entry is surfaced to the user. Deploy the Intune trusted certificate profile and verify presence with certutil -viewstore -enterprise Root before rollout.

PIN lockout

PIV cards have a hardware PIN retry counter — typically 3 to 10 attempts depending on the card model. Exceeding the limit permanently locks the PIN; recovery requires a card management operation using the PIN Unblocking Key (PUK), or re-issuance depending on your card program policy.

This is a physical security feature of the card, not a configurable Entra or Intune setting. Communicate the PIN lockout threshold to users before rollout. Unlike an Entra account lockout that clears after a time window, a locked PIV card PIN requires hands-on card management.

Checklist: PIV / CBA

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.
Intune: Deploy trusted certificate profile (root + intermediate CAs) to PIV workstations before rollout.
Conditional Access: Require phishing-resistant authentication strength for affected users or locations.
Test: Sign in with a PIV card on an NFC reader and confirm PRT is issued (dsregcmd /status → AzureAdPrt: YES) before rollout.

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 4 (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.