Phishing-resistant MFA for Essential Eight with Entra ID

Which phishing-resistant MFA for the Essential Eight with Entra ID methods qualify

If a customer, contract or regulator now expects Essential Eight at Maturity Level 2 or higher, the MFA requirement is specific: ML2 requires phishing-resistant MFA for staff on online services and systems, and cryptographic methods bound to the session qualify while one-time codes do not. That distinction decides which Microsoft Entra authentication methods you can rely on, so it should be settled before anyone configures a policy. Your organization owns the controls and the decision about which methods satisfy them. DeployOpen prepares the Entra configuration, device enrollment and evidence, but an independent assessor is the only party who issues any assessment outcome. The answer also varies by tenant, device fleet and user population, so the list below is a starting point for your own review, not a verdict on your environment.

Microsoft's guidance on Essential Eight MFA, based on the NIST SP 800-63B requirements that ASD's MFA requirements draw on, identifies the Entra methods that meet Maturity Levels 2 and 3 as those using cryptographic authenticators that bind the authenticator output to the session. In practice, confirm the following for each population: whether passkeys (FIDO2) and Windows Hello for Business are enabled in the authentication methods policy, whether SMS, voice, email and Microsoft Authenticator push or number matching remain available to the same users, and whether Conditional Access requires an authentication strength that excludes the weaker methods. Also confirm how Windows Hello for Business keys are provisioned and whether identity proofing, such as the Entra Verified ID option Microsoft suggests with an identity verification partner, is in place before credentials are issued. Ask your Microsoft specialist to show the policy evaluation for each group.

Be aware that an enabled phishing-resistant method does not satisfy the requirement while a weaker method remains a valid fallback for the same users. Self-service password reset, account recovery and temporary access pass processes are common places where a weaker path quietly survives. Document the exceptions you accept, who approves them and how long they last, and confirm that successful and unsuccessful MFA events are centrally logged under ISM-1683. A useful check is to attempt a sign-in with each method a user could reach, then compare the result to the policy you wrote. Your assessor will test this behavior, and that test is the evidence that matters.

Which Entra authentication methods meet ML2 and ML3

Windows Hello for Business is the method most organizations with managed Windows devices consider first. It uses a biometric or PIN to unlock a key or certificate bound to the device's Trusted Platform Module, so the credential stays on the device. Microsoft's guidance treats this kind of cryptographic authenticator as the basis for phishing resistance at ML2 and ML3.

Device binding: the private key sits in the TPM, so a password captured by a phishing page cannot be replayed to sign in from another machine.
Trust model: confirm whether your tenant uses key trust or certificate trust, because the deployment steps and the evidence you keep differ between them.
Unlock controls: document the PIN complexity and biometric enrollment settings you enforce through Intune or Group Policy.
Managed device scope: Hello applies to enrolled Windows devices, so staff on unmanaged or personal devices need another qualifying method.
Recovery process: assessors often ask who can reset a Hello credential and how identity is checked first, so record that process before the assessment.

Confirm with Microsoft, against the documentation for your Windows versions, which trust model and enrollment settings apply before you cite Windows Hello as evidence.

Verifying identity before issuing phishing-resistant credentials

A phishing-resistant authenticator is only as trustworthy as the identity check that preceded its issuance. The steps below cover how the organization proofs a person, binds the credential to the right account, handles recovery and records the procedure. The organization sets and owns the proofing rule; Microsoft's guidance points to Entra Verified ID with an identity verification partner as one option.

Set the proofing rule

The organization decides what counts as sufficient proof of identity before a phishing-resistant credential is issued, including which documents, in-person checks or verified sessions are accepted. This rule belongs to the organization's security and HR owners, not to the MFA vendor or implementation partner. Write it down as a policy, state who may approve exceptions, and confirm it matches the assurance level your Essential Eight target requires. Ask your assessor which proofing evidence they will want to see.

Use Verified ID with a partner

Microsoft suggests Microsoft Entra Verified ID with an identity verification partner to confirm a person's identity before issuing phishing-resistant credentials. Verified ID is a Microsoft service, and the verification partner performs the proofing under your rule. Confirm which partners Microsoft currently supports in your tenant and region, what data they retain, and where that record sits in your own evidence set. The partner does not replace your decision about who is approved.

Bind the credential to the user

Once proofing succeeds, the credential must be enrolled against the correct Entra ID account and no other. For Windows Hello for Business, the key or certificate is bound to the device TPM and unlocked by a PIN or biometric, so the enrollment step links a specific user, device and TPM. Check that the account being enrolled is the verified person, that enrollment cannot be completed by someone else, and that the binding is logged. Mismatched bindings are a common route for account takeover.

Handle recovery without weakening MFA

Recovery paths are where phishing-resistant MFA often gets bypassed. A lost device, a reset request or a temporary access pass can reintroduce a one-time code or a helpdesk call that an attacker can manipulate. Define who may approve a recovery, how that person verifies the requester again, and how long any temporary access lasts. Test the process with a helpdesk scenario before go-live, and confirm with your identity team which recovery methods Entra ID allows in your configuration.

Retire lost or compromised credentials

When a device is lost, stolen or reported compromised, the associated Windows Hello for Business key or certificate should be revoked and the user re-proofed before a replacement is issued. Establish a clear reporting channel, a revocation step with a named owner, and a record of the time between the report and revocation. Ask your implementation partner to show how revocation appears in the logs you will later present as evidence.

Document the procedure as evidence

An assessor will ask how each credential was issued and whether the steps were followed every time, not only described in a policy. Keep the proofing rule, the approved verification method, enrollment records, recovery approvals and revocations in a controlled repository with dates and approver names. Pair these with the MFA sign-in and enrollment logs that the Essential Eight requires to be centrally logged. Sample your own records quarterly so gaps are found before an assessment does.

What MFA event logging must show for ISM-1683

ISM-1683 requires that successful and unsuccessful MFA events are centrally logged. For a Microsoft Entra ID tenant, the assessor will want to see that sign-in activity, including the interactive and non-interactive sign-ins that carry MFA results, leaves Entra ID and lands in a store the organization controls, where it can be queried after the fact. The point is not that the logs exist in the Entra admin portal. It is that a failed phishing-resistant sign-in and a successful one can both be shown, with timestamps, user, application and the authentication method used, from a source independent of the identity provider's own console.

In practice, the reader should confirm three things in their own tenant. First, that the Entra diagnostic settings export sign-in logs to a central destination, such as a Log Analytics workspace, storage account or event hub feeding a SIEM, and that the export covers both successful and failed sign-ins. Second, that the retention period in the chosen store is set by the organization and written into its logging standard, since the assessor will check that logs are kept long enough to investigate an incident. Third, that someone can produce a sample report showing a deliberate failed MFA attempt and its matching successful sign-in, because that is the evidence an assessor will ask to see first.

The organization owns the log pipeline, the retention period, the alerting rules and the people who review the events. An implementation partner can configure the export, build the queries and document the setup, but the retention decision and the evidence of review remain the organization's responsibility. Confirm the exact Entra log export options, licensing needed for the chosen retention, and SIEM ingestion costs with the vendors and within your own environment before the assessment, because these details change and vary by tenant.

How to move from one-time codes to phishing-resistant MFA

The sequence moves staff from one-time codes to cryptographic sign-in methods in an order that protects privileged and data repository users first, and ends with evidence that the weaker methods are gone. Each phase produces a document or report that the next phase depends on.

Inventory current methods and users
Identity administrators export the authentication method registration report from Microsoft Entra ID and match it against directory groups for administrators, data repository users, online service users and everyone else. The output is a register listing each user, the methods they have registered, and whether they can sign in without a second factor. Confirm the report covers guest and service accounts, because these often rely on SMS or email codes and are easy to miss. The step is done when every active account appears in the register with an owner for any exception.
Select methods that qualify as phishing resistant
The identity team, with the security owner, chooses the methods that meet the phishing-resistant requirement for ML2 and ML3, such as Windows Hello for Business on managed devices and FIDO2 security keys for users who need a portable option. Each selection is checked against the Essential Eight MFA guidance and the relevant ISM controls, and methods that depend on typed codes are excluded from the approved list. The output is a signed-off method policy that names the approved methods and the users each one covers. Confirm with your assessor which method combinations they will accept before you finalize the list.
Pilot for privileged and repository users first
Enroll administrators and users of data repositories in Windows Hello for Business or FIDO2 keys before other staff, because these accounts carry the highest impact if phished. The pilot group provides hands-on feedback on enrollment, account recovery and help desk procedures, and the team records every issue it finds. The output is an enrollment record for each pilot user, a tested recovery procedure, and a list of fixes made before wider rollout. The pilot is complete when every pilot user has signed in with a qualifying method and the help desk has resolved a recovery scenario using the documented procedure.
Verify identity before issuing credentials
Before a phishing-resistant credential is issued, the organization confirms the person's identity through an agreed process, such as an in-person check or a verified identity service. Microsoft suggests Entra Verified ID with an identity verification partner for this purpose. Record the verification method used for each issuance so the link between person and credential can be shown to an assessor. The output is an issuance log that ties each credential to a verified identity and a named approver.
Enforce conditional access policies
Identity administrators create Conditional Access policies that require an approved phishing-resistant method for administrators and data repository users, then extend the requirement to other staff once the pilot is stable. Policies are first tested in report-only mode, and the team reviews sign-in logs to find users or applications that would be blocked. The output is a set of enforced policies with documented exclusions, each approved by the security owner and linked to the method register. The step is complete when sign-in logs show qualifying methods for all targeted users and each exclusion has an expiry review.
Decommission weaker methods
Once enforcement covers each user group, the identity team disables SMS, voice, email and one-time code methods for those users and removes them from the registration options where the tenant configuration allows. Users are told in advance which method replaces the old one, and the help desk tracks exceptions. The output is a configuration change record showing which methods were disabled, when, and for which groups. Confirm that the removal also applies to legacy sign-in paths and that no service still depends on a code-based method.
Log MFA events and collect evidence
The team confirms that successful and unsuccessful MFA events are sent to the central log store, so that both outcomes can be reviewed and retained as the ISM requires. It then assembles an evidence pack containing the method register, method policy, enrollment records, issuance log, Conditional Access configuration, decommissioning record and sample sign-in logs. The output is a dated evidence pack mapped to the relevant controls, which an independent assessor can test. Note that DeployOpen prepares this evidence, while the assessor decides whether it satisfies the requirement.

What to confirm before an assessor reviews the MFA controls

An assessor will start with the sign-in population, the methods those accounts can actually use, and the logs that prove it. Confirm these five areas before the review so the evidence you hand over matches the tenant as it runs today, not as it was configured.

Accounts in scope, including data repository users

Export the full list of human accounts that sign in to online services, systems and data repositories, then compare it with the Entra ID user and group population. ML2 covers staff on online services and systems, and ML3 adds human users of data repositories under ISM-1505, so service and shared accounts need a documented decision rather than silent exclusion. Record which accounts are excluded, who approved the exclusion and why. The export and the exclusion register are the evidence an assessor will sample first.

Weaker methods blocked by policy

Review the Entra authentication methods policy and the Conditional Access grants for each in-scope group. Confirm that SMS, voice call, one-time passcodes and other manually entered codes are disabled or excluded for the population that must use phishing-resistant methods. Export the policy configuration and a sign-in report that shows no successful sign-in using a blocked method during the review period. Configuration alone is not enough, so pair the export with the sign-in evidence.

Device TPM status for Windows Hello

Windows Hello for Business binds its key to the device's Trusted Platform Module, so check that each enrolled device reports an active TPM and that the key is hardware-backed. Use Intune or your device inventory to export TPM version and status, and flag devices with no TPM or a disabled TPM for remediation or an alternative phishing-resistant method. Keep the inventory dated, because an assessor will compare the device list with the accounts that sign in with Windows Hello.

Logging of successful and failed events

ISM-1683 requires successful and unsuccessful MFA events to be centrally logged. Confirm that Entra sign-in and authentication method events flow to your central log platform, retention meets your policy, and both success and failure records carry user, method, result and time. Run a test sign-in with a deliberately failed attempt and confirm it appears in the central store. The log export and the test record show the control is operating, not just switched on.

Identity proofing records before credential issue

Phishing-resistant credentials are only as trustworthy as the identity check behind them. Microsoft suggests Entra Verified ID with an identity verification partner to confirm identity before issuing these credentials. Document the proofing method used for each issued credential, the verifier, the date and the approver, and keep the records for the accounts sampled. If you verify identity in person or through an internal process instead, the same records must still show who checked what and when.

Who does what in a phishing-resistant MFA project

Your organization owns the controls. Phishing-resistant MFA is a business decision as much as a technical one: someone must decide which staff and systems are in scope, who may be issued a phishing-resistant credential, and what happens when a device is lost. These decisions sit with the policy owner, the identity proofing owner and the service desk, and they cannot be delegated to a partner or an assessor.

Policy owner: Sets the authentication policy, names the in-scope user populations, and approves any exceptions with an expiry date.
Identity proofing owner: Defines how staff are verified before a phishing-resistant credential is issued, such as in-person checks against an approved identity document.
Service desk: Runs credential reset and recovery under a documented procedure that does not fall back to a weaker method.
Operations staff: Review failed and successful MFA events and act on anomalies in the central log.
Records owner: Keeps the policy, exception register and enrollment records that an assessor will ask for.

Confirm with your team that each of these roles has a named person and a backup, and that the service desk procedure has been tested against a lost-device scenario.

What usually delays Essential Eight MFA projects

Phishing-resistant MFA rarely stalls on the authenticator itself. Delays usually come from applications, devices, recovery processes and logging that were never designed around the requirement. Each card below names one of these blockers and the check to run before the project is scoped.

Legacy applications that only accept passwords

Older line-of-business applications and some on-premises services authenticate with a username and password against their own store, so Entra ID never sees the sign-in. Inventory every application that serves staff or data repositories and record how each one authenticates. Where an application cannot federate with Entra ID, plan a front-end gateway or a replacement before the MFA date, not after. Confirm the vendor's supported sign-in methods in writing.

Shared accounts used across staff

Shared logins for service desks, shift teams or shared mailboxes cannot be bound to one person's phishing-resistant credential, so they undermine the attribution that MFA logs are meant to provide. List every shared account, decide whether it can become individual accounts, and where it cannot, document the compensating control and its owner. Auditors will ask who authenticated, so the answer must be traceable to a named person.

Unmanaged devices without a TPM

Windows Hello for Business binds its key to the device's Trusted Platform Module. Devices without a TPM, or with a TPM that is disabled or unhealthy, cannot hold that key, so they cannot meet the requirement through that route. Query the device inventory for TPM presence and version before choosing the rollout order. Retire or replace noncompliant hardware, and block sign-in from unmanaged devices with Conditional Access so they cannot fall back to weaker methods.

Service desk recovery that falls back to codes

The most common weakness appears after rollout. When a user loses a phishing-resistant authenticator, the service desk may reset the account and issue a temporary access pass or a one-time code, which an attacker can also phish. Define a recovery procedure that requires identity verification, such as the approach Microsoft describes with Entra Verified ID, and restrict which methods can be used to re-register. Test the procedure with the help desk before go-live, and log each reset.

Authentication methods left enabled

Entra ID tenants often keep SMS, voice, email and one-time code methods enabled for legacy reasons after phishing-resistant methods are added. A user who can still choose a weaker method will eventually do so, and the MFA requirement is then met only on paper. Review the authentication methods policy and Conditional Access authentication strengths, then disable or scope out each weaker method. Record the change so the configuration can be shown to an assessor.

Missing MFA event log exports

ISM-1683 requires successful and unsuccessful MFA events to be centrally logged. Sign-in logs in Entra ID are retained for a limited period by default, and many teams never export them to a central store, so evidence disappears before the assessment. Confirm that sign-in and audit logs stream to your SIEM or log platform, that failed as well as successful attempts are captured, and that retention covers the assessment period. Test a sample export before the assessor asks for one.

Common questions about Essential Eight phishing-resistant MFA

Do Microsoft Authenticator push notifications count as phishing-resistant MFA?

Not automatically. Microsoft's Essential Eight MFA guidance says the Entra authentication methods that meet Maturity Levels 2 and 3 use cryptographic authenticators that bind the output to the session. Push approvals, including number matching, need to be checked against that list before you count them. Read the Microsoft Learn Essential Eight multifactor authentication guidance and confirm with Microsoft which methods qualify for your tenant and client versions. Whatever you choose, one-time codes from the app or SMS do not qualify, because they are manually entered and can be relayed to a fake sign-in page. Record the method your assessor will test, and keep the policy that restricts sign-in to it.

Is Windows Hello for Business enough for every user?

Usually not on its own. Windows Hello for Business unlocks a key or certificate bound to the device's Trusted Platform Module with a PIN or biometric, which fits the phishing-resistant requirement for users on enrolled devices. The gaps are predictable: shared kiosks, contractors on unmanaged devices, service-style accounts, and staff who sign in from phones or browsers without a suitable device. Each group needs a documented path to a qualifying method, or a restriction that stops them from reaching the protected services. Confirm the exact device and sign-in scenarios supported with Microsoft before you write the policy, and list the exceptions in your scope statement so the assessor can test them.

Will we need to change our Microsoft licence to do this?

It depends on your current licence and the features your tenant needs, so confirm it with Microsoft before you buy anything. The features used for phishing-resistant sign-in, conditional access, device management and identity verification may sit in different licence tiers, and tiers change over time. Ask your Microsoft account team or licensing partner to map each feature in your design to the licence that includes it, in writing, with the date of the answer. DeployOpen does not resell Microsoft licences and is not a Microsoft partner, so this question should go to Microsoft or your reseller.

How long does phishing-resistant MFA take to roll out?

The duration depends on scope, and no supplied figure gives a general timeline. The main drivers are the number of users and their roles, how many devices need enrollment, how many applications and systems must move to conditional access, whether identity verification is needed before credentials are issued, and how many exceptions must be handled. Staged rollouts usually take longer than a single cutover because pilot groups, fallback paths and help desk changes all need time. Ask for a timeline in the written scope, with milestones tied to user groups and evidence, not a single date. Any timeline should also account for the time to collect and retain MFA event logs.

What does the internal team need to provide?

The internal team owns the controls, so it must supply the decisions and access that an outside partner cannot make alone. Typical needs include:

An identity administrator to own the Entra ID configuration and approve the authentication method policy.
A device management owner for Intune enrollment and the Windows Hello for Business settings.
A security or SOC contact who will receive MFA sign-in events and confirm they are centrally logged.
An HR or service desk owner to run identity verification before credentials are issued and to handle recovery.
A named approver for exceptions, so each one is documented and time-limited.

Each role should have enough time booked to test sign-in on real user groups, not only in a lab.

Can our own team implement this without outside help?

Yes, if your team already runs Entra ID conditional access, Intune and centralized sign-in logging, and has the time to test on real users. The work is configuration and evidence rather than new technology. The harder parts are usually the exceptions, identity verification steps, and producing evidence that an assessor can trace from policy to sign-in logs. If those skills are thin, an implementation partner can plan the design, configure the tenant and prepare the evidence, under a written scope. DeployOpen implements and documents open-source and self-hosted platforms in client environments and prepares evidence for assessments, but it does not issue assessment results or certificates. Independent assessors do that.

What evidence should we keep for MFA event logging?

Keep records that show successful and unsuccessful MFA events are centrally logged, as the ISM control for MFA event logging requires. In practice, this means exporting sign-in and authentication method events from Entra ID to a central store your security team controls, retaining them for a period your policy sets, and showing that failed attempts are visible and reviewed. Assessors usually ask for a sample of events, the configuration that sends them, and proof that someone acts on alerts. Confirm your retention period with your assessor and check which log categories your licence includes before you promise full coverage.

How DeployOpen prepares Entra MFA evidence for assessment

DeployOpen plans, implements, documents and hands over Entra ID phishing-resistant MFA as part of a self-hosted or customer-controlled environment, so the organization can show its assessor how each sign-in method works and what evidence it produces. DeployOpen prepares systems, controls and evidence only; the organization owns its controls, and an independent assessor issues any conclusion about maturity.

How we scope

We agree a written, fixed scope listing which Entra authentication methods, user groups and online services are in it.
We confirm the target Essential Eight maturity level and which ISM controls the MFA evidence must support.
We identify which staff roles, admin accounts and data repositories need phishing-resistant sign-in, and record exclusions in writing.

How we build

We configure Entra authentication methods and policies so only approved phishing-resistant methods are available for in-scope users.
We set up Windows Hello for Business or security key enrollment and document the enrollment steps the organization must repeat.
We route successful and unsuccessful MFA sign-in events to the organization's central logging so they can be reviewed and retained.

How we hand over

We deliver a written record of the configured policies, enrollment process and identity verification steps for the assessor.
We provide test results showing one-time codes are blocked for in-scope users and that phishing-resistant sign-ins succeed.
We document the owner, review cadence and evidence location for each MFA control so the organization can maintain it.

How we support

Ongoing support, upgrades and continuous testing of the MFA configuration are available as a retainer.
We can rerun sign-in and logging tests when Microsoft changes authentication methods or when the organization changes its ISM baseline.
Before any assessment, we confirm with the organization which evidence the independent assessor will request and whether the scope still matches.