What secondary factor method is used for MFA (SMS / Authenticator / Hardware key / Biometric)?
This question appeared on applications because attackers learned to defeat the weaker factors. Answering it accurately requires reading what your users have registered, not what your policy prefers.
What the carrier is actually asking
The carrier wants to know which second factor is actually in use: a text message, a push notification, a code from an authenticator application, a hardware security key, or a biometric bound to a device. It is a proxy question for phishing resistance. Text messages and simple push approvals can be defeated by interception, SIM swap, or by tiring the user into approving; hardware keys and platform authenticators bound to the origin cannot be phished in the same way.
Why it is underwritten
Adversary-in-the-middle phishing kits made this distinction commercially significant. A carrier that pays business email compromise claims sees the difference between a tenant where a stolen session token was enough and a tenant where the factor was bound to the device and the origin. Factor strength is starting to appear as a rating input rather than a footnote, and phishing-resistant factors on administrators are the version of this answer most likely to earn a credit.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Entra ID records registered authentication methods per user, which makes this one of the few application questions that can be answered with a distribution rather than an adjective. That distribution is a stronger answer than a claim about policy.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | Protection > Authentication methods, policy configuration | Which methods are enabled tenant-wide, and for which groups. A method left enabled is a method an attacker can steer a user toward |
| Entra ID | Authentication methods activity and user registration details | The actual registered method mix across the population, not the preferred method on paper |
| Entra ID | Microsoft Authenticator settings, number matching and additional context | Number matching is enforced rather than left to the tenant default, which is what breaks push fatigue attacks |
| Entra ID | FIDO2 security key policy and Windows Hello for Business state | Phishing-resistant methods are enabled and, ideally, required for administrators through authentication strength |
| Entra ID | System-preferred multi-factor authentication | Enabled, so users are steered to the strongest method they have registered rather than to the one they used first |
A tenant can have hardware keys deployed to the security team and still allow every one of them to fall back to a text message. Authentication strength in Conditional Access is what turns a deployed factor into an enforced one, and it is the difference an underwriter is trying to detect.
What a defensible yes requires
- You can state the method mix as a distribution across the population rather than as a single label.
- Text message and voice call are disabled, or restricted to a named group with a reason, rather than left available as a universal fallback.
- Number matching and additional context are enforced for push notifications.
- Administrators are held to a phishing-resistant authentication strength, not merely to any second factor.
- System-preferred multi-factor is on, so the strongest registered method is the one offered.
How this answer goes wrong
The usual mistake is answering with the intended standard. An organisation that rolled out Microsoft Authenticator answers "authenticator app" while a third of its users still have a phone number registered as a fallback and will use it the moment the app is inconvenient. The registration data says something different from the rollout plan, and the registration data is what an attacker interacts with.
The other mistake is treating hardware keys as a completed project because they were purchased. Keys in a drawer are not a factor. Keys enrolled but not required are a preference.
Frequently asked
Is SMS still acceptable to carriers?
Broadly yes for general users today, and increasingly not for administrators. The trajectory is clear enough that treating text message as an interim measure rather than a destination is the safer planning assumption.
What counts as phishing-resistant?
FIDO2 security keys, Windows Hello for Business, and certificate-based authentication bind the credential to the device and the origin, so a proxy site cannot relay them. Push notifications and one-time codes can be relayed, which is why they sit in a different tier.
Do we need hardware keys for everyone?
Rarely proportionate. The pattern that answers this question well is phishing-resistant factors for administrators and anyone who can move money, with number-matched push for the general population.
How do we prove the method mix?
Entra ID reports registration by user, so it can be exported as a dated distribution. That export is materially better evidence than a screenshot of the authentication methods policy, because it shows state rather than intent.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture