--- title: "What secondary factor method is used for MFA (SMS / Authenticator / Hardware key / Biometric)?" url: https://insuranceposture.com/questions/multi-factor-authentication/secondary-factor-method-mfa category: "Multi-factor authentication" canonical_key: q_idn_008 evidence_state: verified updated: 2026-08-24 --- # What secondary factor method is used for MFA (SMS / Authenticator / Hardware key / Biometric)? URL: https://insuranceposture.com/questions/multi-factor-authentication/secondary-factor-method-mfa Section: Multi-factor authentication Evidence state: Verifiable from your tenant 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 | **Registered is not the same as required** 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. ## If this answer turns out to be wrong Multi-factor answers are the ones a carrier can most easily show were material, because most US forms gate quoting on them rather than merely rating them. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [how materiality is decided](https://insuranceposture.com/glossary/materiality). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary). ## 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 - [Is multi-factor authentication enforced on all email access?](https://insuranceposture.com/questions/multi-factor-authentication/multi-factor-authentication-enforced-email-access) - [Is MFA enforced on all privileged / administrative user accounts?](https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-privileged-administrative-user-accounts) - [Is legacy email authentication (IMAP, POP, basic authentication) disabled?](https://insuranceposture.com/questions/email-security/legacy-email-authentication-disabled) - [Are phishing simulations conducted for all employees, with click rate tracking?](https://insuranceposture.com/questions/email-security/phishing-simulations-conducted-employees-click-rate-tracking) --- Insurance Posture by SecValley. https://insuranceposture.com The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished. SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact. Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.