What is IT AMC in the USA and why do businesses need it?

IT AMC (Annual Maintenance Contract) in the USA is a comprehensive service agreement for maintaining all IT equipment and systems. Businesses need IT AMC for predictable costs, 24/7 support, preventive maintenance, reduced downtime, and expert technical assistance. It's the most affordable way to ensure reliable IT operations.

How much does IT AMC cost in the USA?

IT AMC pricing in the United States is scoped per engagement and depends on the number of devices, support level, and services included. Small businesses with basic coverage sit at the entry level, and comprehensive packages scale with the size of your estate. We offer the best affordable IT AMC solutions in United States with customized pricing.

What is included in managed IT services in the USA?

Our managed IT services in the USA include complete IT infrastructure management, 24/7 monitoring and support, cybersecurity, cloud services, backup and disaster recovery, help desk support, network management, and proactive maintenance. It's a complete IT department solution with affordable monthly pricing.

What is the response time for IT support in the USA?

GR IT Services responds to P1 critical issues in 5 minutes for managed clients, delivered remotely. We offer 24/7 reliable IT support to businesses across the USA with a guaranteed SLA.

Which areas in the USA does GR IT Services cover?

We provide IT support and managed IT services across all major USA cities including New York, Los Angeles, Chicago, Houston, Phoenix, Philadelphia, San Antonio, San Diego, Dallas, and San Jose. We serve businesses nationwide with complete IT support.

Why is GR IT Services the best IT company in the USA?

GR IT Services combines reliable 24/7 support, a 5-minute P1 response SLA, complete IT solutions, and certified Microsoft CSP and Apple Jamf partner status. We provide IT AMC and managed IT services across the USA with a guaranteed SLA and senior engineers on every engagement.

Phishing-resistant MFA for US businesses

Three methods qualify as phishing-resistant. The push notification your organization relies on is not one of them.

Three combinations qualify for the built-in phishing-resistant strength, and only three: Windows Hello for Business or an equivalent platform credential, a FIDO2 security key, and certificate-based authentication in its multifactor form. Push approval through Authenticator clears both the MFA and passwordless bars. It does not clear this one, because nothing in a push ties the approval to the page that asked for it.

Book a phishing-resistant MFA review See what qualifies and what does not

Phishing-resistant multifactor authentication for US organizations

Three methodsWhat the built-in strength actually allows
Three strengthsMFA, passwordless, phishing-resistant
Entra ID P1The license Conditional Access requires
Custom allowedWhere the built-in set does not fit

What qualifies

Seven questions that determine whether what you have deployed is genuinely phishing-resistant.

An authentication strength is a Conditional Access control that names which combinations of methods are acceptable for reaching a given resource. Any allowed combination satisfies it. There are three built in, they are not equivalent to one another, and the space between them is where most companies find out they have a gap.

The whole test is whether the method and the page can see each other

The strength is defined as covering methods that require a genuine interaction between the credential and the surface asking for it. That single idea explains everything else. A code, a push or a prompt has no notion of where it is being presented, so it can be relayed to a page the attacker controls. A credential bound to the origin cannot be relayed, which is why so few methods make the list.

FIDO2 security keys and passkeys

First of the three that qualify, and the only one that clears all three built-in strengths at once. For most American companies this ends up being the answer for administrators, for anyone without a managed Windows machine, and for people who have to sign in from a shared or unmanaged computer.

Windows Hello for Business or a platform credential

Second on the qualifying list, and easily the pleasantest to use, because it is already the gesture people make to unlock the machine in front of them. It clears every strength. The limitation is reach: it only helps where the hardware supports it and the device is enrolled, which in most estates leaves a group of people needing something else entirely.

Multifactor certificate-based authentication

Third on the list, and the reason companies already running a certificate authority frequently arrive at phishing-resistant sooner than they thought possible. Read the qualifier carefully though, because only the multifactor variety counts. The single-factor form sits in the published table satisfying none of the three strengths at all.

Authenticator push does not qualify, and that surprises people

Phone sign-in through Authenticator clears MFA and passwordless and does not clear phishing-resistant. Nor does a Temporary Access Pass, a password plus a second factor, federated multifactor, or SMS. For most American companies that means what they built two years ago is genuinely good, and genuinely not what this asks for.

Built-in strengths update themselves, custom ones do not

The built-in strengths are permanently present, cannot be edited, and gain new methods as Microsoft adds them. A custom strength lets you name precisely which combinations you will accept, which is handy while you are in transit, and the price is that you now own its upkeep. Our habit is built-in for where you are going and custom only for how you get there.

Strengths apply per scenario, not per tenant

The supported scenarios are set out plainly: a specific method for a sensitive resource, for a sensitive action within an application using authentication context, for access originating outside the network, for accounts flagged as high risk, and for guests reaching your tenant alongside your cross-tenant settings. Between them, those are what make a staged rollout achievable.

The limitation to understand before you promise anything

None of this prevents somebody typing their password into a fake page.

It is stated plainly in the documentation, and it changes what you can honestly say about credential theft afterward.

The wording is worth quoting: policies are evaluated only after the first authentication has happened, so a strength places no restriction on that initial step. The password can still be typed. What follows is that a phishing-resistant method, a security key for instance, has to be presented before anything else proceeds.
In practice, then, a harvesting page still walks away with the password. What it cannot do is finish the job, because the factor that follows is tied to the origin and simply will not function on the attacker page.
That remains a very large improvement, and it is the reason this is worth the work. It does mean, however, that password hygiene, leaked credential detection and identity protection stay on the list rather than coming off it.
Reaching a genuine absence of passwords means deploying passwordless alongside the strength. That is a separate piece of work that sits well next to this one, rather than something the Conditional Access control produces by itself.

Ask us to review your authentication strengths

How we approach it

Four things that get an organization to phishing-resistant without an outage.

None of the technology here is difficult. Every way it goes wrong is operational: an administrator locked out, a help desk that was never briefed, and a group of people nobody realized had no device capable of any of it.

We build the emergency access position first

Demanding this strength of administrative roles is precisely the change capable of shutting out every administrator simultaneously. So the emergency accounts, cloud-only, registered with a qualifying method and excluded from anything that could block them, come into existence before the policy is written, not during the incident afterward.

Scope follows the people and the resources, never a date somebody picked

Strengths were built to be scoped, and the supported scenarios are set out in full. Administrators first, then whoever has a device capable of Windows Hello, then everybody remaining. Switching this on across the tenant on day one produces a help desk queue that gets the project canceled, which leaves the company further back than a slower approach ever would.

We size the key requirement honestly and early

Anyone with neither a Hello-capable device nor a certificate infrastructure behind them needs a physical key, and keys bring purchasing lead times, the logistics of getting them into hands, and a process for the day somebody loses one. Counting that group in the first week is what stops the schedule becoming fiction.

We brief the service desk on the behaviors that generate calls

Two are worth knowing about. If the strength calls for Windows Hello and the person signed in with a password, no prompt appears at all: they have to start the session again and pick a different option. And where a strength and a sign-in frequency are both in force, each can be satisfied at a different moment, which produces behavior that looks broken and is documented.

How we sequence it

Four phases, and administrators go first for a reason.

Rolling this out to everyone at once does not work, because every qualifying method needs either a capable device or a physical credential in somebody hand. Sequencing by group rather than by date is what turns it into something deliverable.

01
Weeks 1 to 2
Administrators and emergency access
Administrators go first, since there are few of them, they are worth the most to an attacker, and they are the group a relay attack is aimed at. The emergency accounts are dealt with in the same breath, because the guidance for those recommends a passkey or certificate-based authentication and they have to be kept out of any policy capable of blocking a sign-in.
- FIDO2 keys issued and registered for every administrative account
- A policy demanding the phishing-resistant strength wherever an administrative role is in play
- Emergency access accounts configured and excluded from blocking policies
- A tested rollback path before the policy is enforced
02
Weeks 3 to 6
The managed Windows population
Windows Hello for Business delivers a phishing-resistant method with nothing to ship out and a gesture people already know, which makes this the quickest group to move across. The way it behaves around the primary sign-in gets explained to the help desk before enforcement, because otherwise it generates calls nobody was expecting.
- Windows Hello for Business enrolled across the eligible estate
- Sign-in options behavior documented for the service desk
- The policy aimed at the enrolled group specifically, never at the entire tenant
- Registration campaign run before any enforcement
03
Weeks 7 to 12
Everyone else, and the awkward cases
Shared machines, kiosks, frontline workers, contractors, and anyone living on a Mac or a phone. This is the point where the remaining population splits three ways: those who need a physical key, those a certificate can cover because the infrastructure is already there, and those who need a narrow exception carrying a date on which somebody looks at it again.
- Security keys issued to populations without an eligible device
- Certificate-based authentication used where PKI already exists
- Exceptions documented with owner, reason and review date
- Guest access strength decided alongside cross-tenant settings
04
Ongoing
Hold the line and close the exceptions
Registration coverage watched, exceptions actually revisited instead of quietly forgotten, and new starters registered for a qualifying method as part of joining rather than three months later. The built-in strengths pick up new methods on their own as they are added, so a policy resting on one keeps getting better while nobody touches it, which is the case for using built-in wherever it will do the job.
- Registration coverage reported monthly
- Every exception with a review date attached, and somebody who actually reviews it
- Qualifying method registered during new hire onboarding
- Custom strengths taken back out once the transition they existed for has finished

Where this matters most

Six US situations where phishing-resistant is the right requirement.

What usually prompts the call is a live phishing kit, which puts a genuine sign-in page in front of the victim and passes their code or their approval straight back to the attacker. Nothing survives that except a method bound to the origin.

A financial firm whose administrators are individually targeted

Administrators are few, they are worth a great deal to an attacker, and they are the obvious first wave. Requiring the strength on administrative roles, with keys kept at nominated workstations, shuts the route behind the identity compromises that do the most damage. It is also a control that firms under NYDFS Part 500 and the underwriters renewing their cyber policies now ask about by name.

A company that has already lost this fight once

Having watched a relay attack walk straight through push-based MFA, nobody asks whether any more, only how quickly. Applying the strength to the most sensitive applications first produces something defensible inside a few weeks, rather than waiting on a rollout that covers the whole estate.

A company with an existing public key infrastructure

Certificate-based authentication in its multifactor form is one of the three that qualify, so a company already operating a certificate authority for unrelated reasons often has a path here that requires buying nothing at all. The distinction to confirm is that the single-factor form qualifies for none of the three strengths.

An operator with shared and frontline devices

This is the group that causes the most trouble, because Windows Hello assumes a device enrolled to one person and anything phone-based assumes a phone. Physical keys are normally the answer, sometimes issued individually and sometimes shared under a controlled handover. Settling that before enforcement rather than during it is the whole difference between a smooth wave and a bad week.

A healthcare organization with clinical workstation sharing

Signing in and out of a shared workstation in seconds is a real clinical requirement, not a preference, and it sits badly with any method assuming one device belongs to one person. Smartcards backed by certificates, or a key issued to each clinician, are the two routes that work, and both have to be tested against how the floor actually operates rather than how it is described.

An institution protecting a subset rather than everyone

Strengths apply per policy and per resource, so a university can insist on phishing-resistant methods for the finance system, for research data and for administrative roles while leaving ordinary student access on standard MFA. That is a deliberate and defensible design, not a corner being cut.

Three positions

How US organizations authenticate their people today.

The middle column represents a genuinely good place that plenty of companies worked hard to reach, and a competent phishing kit relays straight through it. That is the awkward part of the conversation.

Satisfies MFA requirements

Phishing-resistant strength enforcedYes

App push or code MFAYes

SMS or password onlyPartly

Resists real-time relay phishing

Phishing-resistant strength enforcedYes

App push or code MFANo

SMS or password onlyNo

Resists MFA fatigue attacks

Phishing-resistant strength enforcedYes

App push or code MFAPartly

SMS or password onlyNot applicable

Resists SIM swap

Phishing-resistant strength enforcedYes

App push or code MFAYes

SMS or password onlyNo

Bound to the sign-in surface

Phishing-resistant strength enforcedYes

App push or code MFANo

SMS or password onlyNo

Works without a phone

Phishing-resistant strength enforcedYes

App push or code MFANo

SMS or password onlyNo

Enforced per resource or risk level

Phishing-resistant strength enforcedYes

App push or code MFARarely

SMS or password onlyNo

Method set updates as Microsoft adds methods

Phishing-resistant strength enforcedYes, with built-in

App push or code MFANot applicable

SMS or password onlyNo

Rollout effort

Phishing-resistant strength enforcedModerate

App push or code MFALow

SMS or password onlyNone

Position after a targeted phishing campaign

Phishing-resistant strength enforcedHeld

App push or code MFACompromised

SMS or password onlyCompromised

Feature	Phishing-resistant strength enforced	App push or code MFA	SMS or password only
Satisfies MFA requirements	Yes	Yes	Partly
Resists real-time relay phishing	Yes	No	No
Resists MFA fatigue attacks	Yes	Partly	Not applicable
Resists SIM swap	Yes	Yes	No
Bound to the sign-in surface	Yes	No	No
Works without a phone	Yes	No	No
Enforced per resource or risk level	Yes	Rarely	No
Method set updates as Microsoft adds methods	Yes, with built-in	Not applicable	No
Rollout effort	Moderate	Low	None
Position after a targeted phishing campaign	Held	Compromised	Compromised

What satisfies what

Thirteen method combinations against the three built-in strengths.

Taken from the published comparison. A yes means that combination satisfies that strength. What appears in the lower half is the part most companies are not braced for.

Authentication method combination

FIDO2 security key

MFA strength: Yes
Passwordless MFA: Yes
Phishing-resistant MFA: Yes

Authentication method combination

Windows Hello for Business or platform credential

MFA strength: Yes
Passwordless MFA: Yes
Phishing-resistant MFA: Yes

Authentication method combination

Certificate-based authentication, multifactor

MFA strength: Yes
Passwordless MFA: Yes
Phishing-resistant MFA: Yes

Authentication method combination

Microsoft Authenticator, phone sign-in

MFA strength: Yes
Passwordless MFA: Yes
Phishing-resistant MFA: No

Authentication method combination

Temporary Access Pass, one-time and multiple use

MFA strength: Yes
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

Password plus something the user has

MFA strength: Yes
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

Federated single-factor plus something the user has

MFA strength: Yes
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

Federated multifactor

MFA strength: Yes
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

Certificate-based authentication, single-factor

MFA strength: No
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

SMS sign-in

MFA strength: No
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

Password

MFA strength: No
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

Federated single-factor

MFA strength: No
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination

QR code

MFA strength: No
Passwordless MFA: No
Phishing-resistant MFA: No

Authentication method combination	MFA strength	Passwordless MFA	Phishing-resistant MFA
FIDO2 security key	Yes	Yes	Yes
Windows Hello for Business or platform credential	Yes	Yes	Yes
Certificate-based authentication, multifactor	Yes	Yes	Yes
Microsoft Authenticator, phone sign-in	Yes	Yes	No
Temporary Access Pass, one-time and multiple use	Yes	No	No
Password plus something the user has	Yes	No	No
Federated single-factor plus something the user has	Yes	No	No
Federated multifactor	Yes	No	No
Certificate-based authentication, single-factor	No	No	No
SMS sign-in	No	No	No
Password	No	No	No
Federated single-factor	No	No	No
QR code	No	No	No

How an engagement runs

Five steps, and report-only mode is not skipped.

Eight to sixteen weeks is typical, and where it lands depends almost entirely on how many people need a physical key. The policy itself is a few days of work. Registration, purchasing and the difficult groups are what fill the calendar.

1
Establish licensing, current methods and eligibility
Conditional Access needs P1, so that gets confirmed before anything else. Then we establish what people currently have registered, how many devices could run Windows Hello, and whether there is already a certificate infrastructure capable of delivering the multifactor form.
2
Build the emergency access position
At least two cloud-only break glass accounts, registered with a method that qualifies and kept outside every policy capable of blocking or restricting a sign-in. That happens before any enforcing policy exists at all, because demanding this strength of administrators is exactly the change that locks everybody out at the same moment.
3
Design the policies and run them in report-only
The built-in strength wherever it will serve, and a custom one only where the transition genuinely calls for it. Bearing in mind that the require multifactor control and the require strength control cannot sit in the same policy together. Report-only first without exception, with the impact read against real sign-in data before anything is enforced.
4
Register the population before enforcing on them
Hello enrollment on every device that can take it, keys distributed and registered for the rest, and certificate-based authentication configured wherever the infrastructure is already standing. Each group is enforced only after it has registered, never before, and the help desk gets briefed ahead of every wave.
5
Enforce, then manage the exceptions down
Policies move out of report-only and into enforcement one group at a time. Every exception has a named owner, a stated reason and a date it gets looked at again. Coverage is reported monthly, and new starters register a qualifying method while they are being onboarded, which is the only mechanism that keeps the position from quietly eroding.

Straight answers

What US organizations ask about phishing-resistant MFA.

The built-in strength accepts Windows Hello for Business or an equivalent platform credential, a FIDO2 security key, and Entra certificate-based authentication in its multifactor form. Those three and nothing else. The stated reasoning is that it covers only methods requiring a real interaction between the credential and the surface asking for it.

Correct, and the published table leaves no room for interpretation. Phone sign-in through Authenticator clears MFA and passwordless, and not this one. It remains a genuinely strong defense against reused passwords and credential stuffing. It is not a defense against a live relay attack, because the approval has no idea which site asked for it.

A password plus something the person holds clears MFA and nothing more, where something they hold means a text, a voice call, a push, or a software or hardware OATH token. SMS on its own clears none of the three. Neither does a password by itself, federated single-factor authentication, single-factor certificate-based authentication, or a QR code.

No, and the documentation says so outright. Policies are only evaluated once the first authentication has already happened, so a strength puts no constraint on that step. The password can still be typed, and what has to follow is a phishing-resistant method before anything proceeds. The attacker ends up holding the password and unable to finish the sign-in, which is a large improvement rather than a total one.

Conditional Access needs P1 in the tenant, and since strengths are a grant control within it, the same requirement carries across. Most American companies we deal with already hold P1 through a Microsoft 365 subscription and have simply never switched strengths on.

No. The two grant controls cannot appear together in a single policy, because the built-in multifactor strength is the same thing as the require multifactor control. In practice one replaces the other rather than being added alongside it.

Built-in wherever it will do. Those are permanently present, cannot be edited, and gain new methods as they are added, so a policy resting on one gets better on its own. A custom strength earns its place during a transition where you need to allow a combination the built-in set will not, and earns removal the moment that transition is over.

Requiring particular methods of guests reaching your tenant, alongside your cross-tenant settings, is one of the supported scenarios. There is one carve-out worth knowing: the email one-time passcode method for guests is not currently covered by the available combinations. What you require of guests is a decision to take on purpose, at the same time as your cross-tenant access settings.

It is documented behavior and it reliably generates calls. Sign in with Windows Hello as the primary method and it satisfies any strength that includes it. Sign in with something else, a password say, where the strength requires Hello, and no prompt appears at all. The session has to be started again, sign-in options opened, and a method the strength accepts chosen from there.

This is published as a known issue. Where a resource requires both, the two can be satisfied at different moments. The documented example has a passkey sign-in from yesterday satisfying the strength while a device unlock this morning satisfies a one-hour frequency. It looks wrong, it is the intended behavior, and it is worth knowing before an auditor puts the question to you.

Usually not. Windows Hello qualifies and asks for nothing beyond a device capable of running it, and the multifactor certificate route qualifies wherever the infrastructure already exists. Physical keys are for the people who have neither, which in practice means shared machines, frontline staff, some contractors, and anyone living on a Mac or a phone. Counting that group early is what makes the budget honest.

Yes, and you should. Microsoft designed strengths for exactly that, listing scenarios including sensitive resource access, sensitive actions within an application using authentication context, access from outside the corporate network, and users at high risk. Administrators first, then the eligible device population, then everyone else, is the sequence that works.

Real, and it is the single thing we plan around. Requiring a phishing-resistant strength on administrative roles when an administrator has not registered a qualifying method locks them out completely. Emergency access accounts, report-only mode first, verified registration before enforcement, and a named person who can disable the policy are the four controls that make this safe.

They overlap but are not the same. Passwordless MFA strength includes methods that satisfy MFA without requiring a password, which includes Authenticator phone sign-in. Phishing-resistant is the narrower set. An organization can be passwordless without being phishing-resistant, and can be phishing-resistant while users still hold passwords. Most organizations want both, in that order.

It answers the question those processes are actually asking, but we do not claim it satisfies any named control without checking your specific obligation. Cyber insurance applications, SOC 2 examinations and frameworks like NIST 800-171 and CMMC increasingly distinguish phishing-resistant MFA from ordinary MFA, especially for privileged and remote access. The deployment gives you product evidence; your auditor, assessor or broker owns the interpretation.

We scope per engagement, driven mainly by how many people need physical keys and how many awkward populations exist. The design and policy work is a small part. Hardware, distribution and the registration campaign are the majority, and that becomes a concrete scope within the first week once eligibility is measured.

Before you enforce

Fifteen checks that stop this becoming a Sunday night lockout.

There are not many Conditional Access changes capable of locking every administrator out at once, and this is one of them. Everything in the first group below exists for that reason alone.

Do not lock yourself out

Do you have emergency access accounts?
At least two, cloud-only.
Are they excluded from blocking policies?
Report-only policies do not need exclusion.
Has every admin registered a qualifying method?
Check before enforcing, not after.
Is the policy in report-only first?
Always, without exception.
Who can disable the policy if it goes wrong?
And can they sign in to do it.

Coverage

Which devices support Windows Hello for Business?
That population is the cheapest to move.
Do you have a PKI already?
Multifactor CBA qualifies, single-factor does not.
How many people need a physical key?
Procurement lead time is real.
What about shared and frontline devices?
Usually the hardest population.
Are guests in scope?
Strengths work with cross-tenant settings.

Policy design

Are you mixing grant controls?
Require MFA and require strength cannot be combined.
Is sign-in frequency also applied?
The two can be satisfied at different times.
Built-in strength or custom?
Built-in updates itself as methods are added.
Are we scoping this to a resource, to a risk level, or to the whole company?
Strengths are designed for scoping.
Does the service desk know the Hello behavior?
Users are not prompted, they must reselect.

The pages around this one.

Passwordless authentication

The complementary program, and where Windows Hello and passkeys come from.

Conditional Access

The policy framework strengths are a grant control within.

Authentication strength policies

The deeper dive on designing and scoping authentication strength controls.

Next step

Check whether your administrators could sign in tomorrow with a phishing-resistant method.

In most tenants we look at, the answer is that some could and some could not, and nobody has checked. That single question determines whether this is a two week project for privileged accounts or a three month one.

Book a phishing-resistant MFA review See passwordless authentication

Related Services

Explore more solutions that work great with this service

Three methods qualify as phishing-resistant. The push notification your organization relies on is not one of them.

Seven questions that determine whether what you have deployed is genuinely phishing-resistant.

Feature

Phishing-resistant strength enforced

App push or code MFA

SMS or password only

Satisfies MFA requirements

Yes

Partly

Resists real-time relay phishing

Yes

Resists MFA fatigue attacks

Yes

Partly

Not applicable

Resists SIM swap

Yes

Bound to the sign-in surface

Yes

Works without a phone

Yes

Enforced per resource or risk level

Yes

Rarely

Method set updates as Microsoft adds methods

Yes, with built-in

Not applicable

Rollout effort

Moderate

Low

None

Position after a targeted phishing campaign

Held

Compromised

Authentication method combination

MFA strength

Passwordless MFA

Phishing-resistant MFA

FIDO2 security key

Yes

Windows Hello for Business or platform credential

Yes

Certificate-based authentication, multifactor

Yes

Microsoft Authenticator, phone sign-in

Yes

Temporary Access Pass, one-time and multiple use

Yes

Password plus something the user has

Yes

Federated single-factor plus something the user has

Yes

Federated multifactor

Yes

Certificate-based authentication, single-factor

SMS sign-in

Password

Federated single-factor

QR code

Three methods qualify as phishing-resistant. The push notification your organization relies on is not one of them.

Seven questions that determine whether what you have deployed is genuinely phishing-resistant.

The whole test is whether the method and the page can see each other

FIDO2 security keys and passkeys

Windows Hello for Business or a platform credential

Multifactor certificate-based authentication

Authenticator push does not qualify, and that surprises people

Built-in strengths update themselves, custom ones do not

Strengths apply per scenario, not per tenant

None of this prevents somebody typing their password into a fake page.

Four things that get an organization to phishing-resistant without an outage.

We build the emergency access position first

Scope follows the people and the resources, never a date somebody picked

We size the key requirement honestly and early

We brief the service desk on the behaviors that generate calls

Four phases, and administrators go first for a reason.

Administrators and emergency access

The managed Windows population

Everyone else, and the awkward cases

Hold the line and close the exceptions

Six US situations where phishing-resistant is the right requirement.

A financial firm whose administrators are individually targeted

A company that has already lost this fight once

A company with an existing public key infrastructure

An operator with shared and frontline devices

A healthcare organization with clinical workstation sharing

An institution protecting a subset rather than everyone

How US organizations authenticate their people today.

Thirteen method combinations against the three built-in strengths.

FIDO2 security key

Windows Hello for Business or platform credential

Certificate-based authentication, multifactor

Microsoft Authenticator, phone sign-in

Temporary Access Pass, one-time and multiple use

Password plus something the user has

Federated single-factor plus something the user has

Federated multifactor

Certificate-based authentication, single-factor

SMS sign-in

Password

Federated single-factor

QR code

Five steps, and report-only mode is not skipped.

Establish licensing, current methods and eligibility

Build the emergency access position

Design the policies and run them in report-only

Register the population before enforcing on them

Enforce, then manage the exceptions down

What US organizations ask about phishing-resistant MFA.

What actually counts as phishing-resistant?

Our Authenticator push MFA is not phishing-resistant?

What about SMS, voice or an authenticator code?

Will this stop somebody typing their password into a fake page?

What license do we need?

Can one policy demand both MFA and a strength?

Built-in strength or a custom one?

What happens to guests?

Somebody was never prompted for Windows Hello. Why not?

We configured a strength and a sign-in frequency, so why does getting in still feel too easy?

Do we need to buy hardware keys for everyone?

Is it possible to do this for only part of the company?

What is the risk of locking ourselves out?

How does this relate to passwordless?

Will this satisfy our cyber insurance or compliance requirements?

What does an engagement cost?

Fifteen checks that stop this becoming a Sunday night lockout.

Do not lock yourself out

Coverage

Policy design

The pages around this one.

Passwordless authentication

Conditional Access

Authentication strength policies

Check whether your administrators could sign in tomorrow with a phishing-resistant method.

Related Services

Conditional Access Authentication Strengths

Microsoft Entra Token Protection

Passwordless Authentication and Passkeys

Microsoft Entra Conditional Access Design

MFA Solutions