Intune Mobile Passkeys and Credential Provider: Small Change, Useful Control

Mobile access is not secondary access anymore. For many teams it is how email gets approved, Teams gets used after hours, documents get shared, and passwords quietly stop being the center of the sign-in flow.

So this post needs one factual correction up front. The useful term in Microsoft's current documentation is passkey provider, not some generic mystery layer called "credential provider". On iOS and Android, Microsoft Authenticator can act as the passkey provider for Microsoft Entra ID passkeys.

That sounds small. It is not. It changes how users register and use stronger sign-in on the device they already carry all day.

Practical mobile baseline

Area	Baseline
Authentication	MFA with passkeys where the device and rollout are ready
App access	Managed Microsoft apps for business data
Data leakage	App protection policies
Device trust	Compliance for enrolled devices where needed
Lost device	Wipe or selective wipe process
Exceptions	Named owner and review date

Why passkeys matter on mobile

Phones are often the easiest place to get users onto stronger sign-in because the hardware, biometrics, and daily habit are already there. Microsoft documents passkey registration in Authenticator on iOS 17+ and Android 14+, with the app acting as the provider for Entra passkeys.

That gives you a more phishing-resistant path than just hoping MFA prompts are enough. It also introduces some practical questions that deserve real answers:

1. Who can register passkeys?
2. Which mobile OS versions are acceptable?
3. What happens when the phone is lost or replaced?
4. Can support recover access without weakening the process?
5. Are legacy methods being reduced, or only piled on top?

Microsoft also notes that Authenticator passkeys are device-bound, not synced. That is a good security property, but it means your recovery story needs to be thought through before rollout day.

Intune still matters, even when the device is personal

Not every business will force full enrollment on personal phones. Microsoft supports app protection policies on unenrolled iOS and Android devices, which is why MAM without enrollment remains such a useful BYOD pattern.

That gives you a sensible middle ground:

• protect Outlook, Teams, and OneDrive data inside the app
• require a PIN or biometric gate for work data
• block casual copy-and-paste into personal apps where appropriate
• selectively wipe business data when access should end

It is not the same as device management. It is still much better than doing nothing.

Do not ignore phones

A beautifully managed Windows fleet with wide-open phone access is a half-finished control model. Users do not separate "mobile risk" from "real risk", and attackers definitely do not.

The casual mistake here is assuming stronger sign-in on desktop fixes weak mobile access. It does not. If the phone is where approvals, mail, and file access happen, the phone belongs in the same control conversation.

The useful target is not perfection. It is a mobile access model you can explain without hand-waving: which devices are allowed, which apps are protected, which users can register passkeys, and what happens when a handset disappears on a Friday night.

References

• How to enable passkeys (FIDO2) in Microsoft Entra ID
• Register passkeys in Authenticator on Android and iOS devices
• Create and Deploy App Protection Policies