“We keep resetting one person’s MFA at a time—who actually set the rule?”

One reset fixes one person. A policy decides everyone, on purpose.

Password and MFA resets solve a single moment. Conditional Access and a clear multi-factor policy decide what every sign-in requires, for every app, before a reset is ever needed—the difference between reacting each time and having already decided.

Discuss your sign-in policy

Multi-factor authentication baseline

Whether MFA is required, for whom, and with which exceptions.

Good desk starting points

Enrolling a new starter’s authenticator app on day one
Applying an already-approved MFA requirement to a specific group
Checking which accounts have not yet registered a second factor
Swapping a lost device’s registered method for a new one

Conditional Access rules

Which sign-ins get challenged, blocked, or waved through, and why.

Good desk starting points

Checking whether a specific sign-in was blocked correctly or in error
Adding a named device or location to an already-approved trusted list
Explaining why one app is prompting for extra verification
Applying an approved rule change to a specific group

Single sign-on for the apps that matter

Which business apps sign in with Microsoft 365, and which still use a separate password.

Good desk starting points

Confirming whether a specific app already supports Microsoft sign-in
Adding an approved user or group to an existing single sign-on app
Troubleshooting a sign-in loop or blank screen on a connected app

Why this becomes worth deciding now

None of these need an incident to justify the conversation.

A written policy is most useful before one of these asks for it, not after.

A cyber-insurance renewal

Insurers increasingly ask for a specific, named MFA policy before renewing—or before honouring a claim.

A new client contract

Some business customers now require proof of MFA and access controls before they will sign.

Every new app is a new decision

Each added tool is a fresh choice between single sign-on and one more stray password.

A departure, or a close call

A departing employee or a near-miss is when most teams first ask what their sign-in policy actually is.

Set the expectation

Applied on request. Decided by your business.

Does the desk decide how strict our policy should be?: No. Strictness is a business decision, sometimes made alongside legal counsel, an insurer, or a specific client contract. The desk can apply an approved policy and explain the trade-offs.
Is this a security audit or penetration test?: No. It is policy setup and upkeep, not a hardening review or an investigation.
Does every app support Conditional Access or single sign-on the same way?: No. Support varies by vendor and licence tier, confirmed per app rather than assumed.
Is a recurring policy review included with Essential?: Applying an already-decided policy is everyday support on both plans. A recurring review of the policy itself sits closer to the light security-baseline support named on the Plus plan.

Common questions

Who decides, and who applies the decision.

Do we need Conditional Access if we are a small team?

A baseline “MFA for everyone” rule is already a form of Conditional Access. Whether you need more than that depends on your apps and risk, not a fixed headcount.

What if a rule blocks someone with a legitimate reason?

A named exception process, approved by an authorized person, is part of a workable policy—not a workaround that quietly becomes the rule for everyone.

Can the desk set our policy without any input from us?

No. The desk can apply an approved rule and explain the realistic options; deciding how strict the rule should be needs your business’s own sign-off.

Related guides

Policy decides the rule. Resets fix the moment.

Password and MFA resets →Email security and phishing triage →

One reset fixes one person. A policy decides everyone, on purpose.

Policy decides the rule. Resets fix the moment.

One place for everyday Microsoft 365 questions to begin.

Related services