Microsoft Authenticator can hold a passkey, it costs nothing, and it is already installed on most staff phones. Against that, buying hardware keys looks like paying for something you have been given.
The app does satisfy phishing-resistant MFA in Entra ID, and for a lot of organisations it is where the rollout should start. But the two options fail in different ways, and the failure modes are what you are actually choosing between.
What they have in common
Both are FIDO2 credentials. Both are bound to the domain they were registered for, which means neither can be phished by a fake sign-in page or relayed through an attacker-in-the-middle proxy. Both satisfy a phishing-resistant authentication strength in Conditional Access.
If someone tells you the app version is weaker cryptographically, they are wrong. That is not where the difference sits.
Where they diverge
The passkey in Microsoft Authenticator is device-bound. It lives in that installation of the app, on that phone, protected by that phone's biometrics or PIN. It does not sync to a new handset.
That single property is where every practical difference comes from.
When a phone is lost, stolen, replaced under warranty or wiped by a factory reset, the passkey goes with it. The user is now locked out and needs a re-registration path, which means either a second registered method or a call to a help desk that can verify who they are. Help desk re-registration is also the attack path that has been used repeatedly against large organisations, because a convincing phone call to a busy service desk is cheaper than any technical exploit. The more often your recovery process runs, the more often it can be gamed.
A hardware key does not care what happens to the phone. It is a separate object with a separate lifecycle, and replacing a handset has no effect on it.
The people the app cannot cover
The same group turns up in every rollout.
Staff who were never issued a work phone. Staff who decline to install a company app on a personal device, which they are often entitled to do. Shared workstations where several people use one login across a shift. Clinical settings and warehouses, and field work where phones are impractical or not permitted. Contractors and temporary staff who need access for six weeks.
You can argue with each of these individually. Collectively they are why a passkey rollout stops short of everyone, and the users left over end up on a weaker method that quietly undoes the point of the project. A hardware key is the answer for that remainder, and it is usually a small enough group that the cost is unremarkable.
Break-glass accounts
This one is not a preference.
Your emergency access accounts, the ones that get you back into the tenant when Conditional Access is misconfigured or an identity provider is unavailable, should not depend on a phone, an app, or a specific person's device. They should depend on a credential in a safe, registered before you need it, tested on a schedule.
A break-glass account whose only phishing-resistant method is an app on the IT manager's phone is a single point of failure holding your entire recovery path, and it takes one wet phone to find out.
A sensible split
Start with Microsoft Authenticator for general staff. It costs nothing and deploys quickly, and it moves the bulk of your users onto a phishing-resistant credential faster than any hardware program can.
Then use hardware keys for the accounts and the people where the app model does not hold. Administrators and privileged roles, finance approvers, break-glass accounts, and the staff the app cannot reach. Two keys each, because a single key is a lockout waiting to happen.
That combination is cheaper than keys for everyone and considerably more complete than the app alone. If you want help mapping which cohorts land where, that is the kind of thing our team works through in a Conditional Access review.