People still obsess over password complexity.

Twelve characters. Special symbols. Rotation every 90 days.

And yet accounts still get compromised.

That’s because attackers don’t guess random passwords anymore. They guess human passwords.

That’s not a complexity problem. That’s a behaviour problem.

So instead of arguing about password rules, I push clients to focus on two things they already have in Microsoft 365:

Password Protection and Smart Lockout.

Quietly running. Often ignored. Rarely tuned.

Here’s what actually matters.

What is Entra ID Password Protection + Smart Lockout, really?

It’s not a password policy.

It’s a filter and a shield.

Password Protection stops users from choosing bad passwords in the first place.

It uses a global banned password list driven by Microsoft telemetry and blocks weak or common passwords automatically—no configuration required. [learn.microsoft.com]

On top of that, you can add your own banned terms. Company names. Locations. Products. The obvious stuff attackers try first.

Then there’s Smart Lockout.

This is what most people misunderstand.

It’s not “lock the account after X attempts”.

That’s old thinking.

Smart Lockout can distinguish between a real user fat-fingering a password and an attacker trying thousands of guesses. [learn.microsoft.com]

Same identity. Different treatment.

Attackers get blocked quickly.

Real users keep working.

That’s not a nicer lockout policy.

That’s a signal-driven control.

“But we already have account lockout on-prem.”

Exactly.

And that’s the problem.

Step-by-Step: Tune Password Protection and Smart Lockout

Portal only. No scripts. No excuses.

1. Open Password Protection settings

Go to:

Entra admin centre
→ Protection
→ Authentication methods
→ Password protection

This is the only place you need.

2. Add a custom banned password list

Add terms like:

• Company name variations
  

• Internal product names
  

• Common abbreviations
  

• Location names

These get evaluated alongside the global list and block weak variants automatically. [learn.microsoft.com]

Not just exact matches.

Variants.

That’s the key.

3. Review Smart Lockout threshold

Default is:

• Around 10 failed attempts before lockout [learn.microsoft.com]

Most SMBs never touch this.

My recommendation?

Lower it slightly only if you understand user behaviour.

Too low and you create support tickets.

Too high and you give attackers room to work.

You’re not tuning numbers.

You’re tuning friction.

4. Set lockout duration

Default starts short (around a minute) and increases with repeated attempts. [learn.microsoft.com]

That’s deliberate.

Short for users.

Painful for attackers.

If you override this, be careful.

Long lockouts punish users.

Short lockouts reward attackers.

5. Leave Smart Lockout on (always)

Important:

Smart Lockout is already enabled.

There’s nothing to “turn on”.

There’s only:

• Leaving it alone
  

• Or breaking it

6. Pair it with MFA (properly)

Password protection is not enough.

Microsoft is very clear on that.

Use it alongside MFA and Conditional Access. [learn.microsoft.com]

Otherwise you’re just slowing attackers down.

Not stopping them.

Why this actually changes behaviour

This is the part most MSPs miss.

These features don’t just block attacks.

They retrain users.

Bad password?

Rejected.

Repeated guessing?

Blocked.

Users learn quickly what works and what doesn’t.

No training session required.

No PDF sent out.

No awareness campaign.

The system corrects behaviour in real time.

“We’ll just educate users instead.”

You can.

Or you can enforce it once and let the platform do it forever.

Ask once. Enforce always.

Here’s the real win:

• Fewer compromised accounts
  

• Fewer lockout tickets
  

• Fewer “why is this happening?” calls

And importantly:

• Better outcomes with less effort

That’s the bit most people overlook.

Notice what’s missing?

No password complexity discussion.

No rotation debates.

No “special characters required”.

Because those don’t solve the real problem.

Attackers aren’t brute-forcing randomly anymore.

They’re spraying expected passwords across thousands of accounts.

Password Protection removes the obvious targets.

Smart Lockout kills the attack path.

Different layers.

Same outcome.

Passwords aren’t going away.

But weak passwords should.

And repeated guessing definitely should.

Password Protection isn’t there to make passwords stronger.

It’s there to make bad passwords impossible.

Most SMB tenants I look at have a “Guest Users” list that’s basically a graveyard. People invited for a project that finished in 2022. A contractor whose engagement ended last March. Somebody’s external accountant who hasn’t signed in since the BAS that prompted the invite.

Nobody removes them. Nobody can remember why they were added. Nobody’s even sure who should remember.

That’s not a guest problem. That’s a governance problem.

Now do the same exercise with Global Administrator. Or Privileged Role Administrator. Or that mystery security group somebody pinned to a SharePoint site three years ago and called “Finance – All”. Same pattern. Stale access. No owner. No expiry.

This is exactly what Access Reviews in Entra ID Governance is built to fix — and most MSPs I talk to either don’t know they’re licensed for it or have never actually run one.

Time to fix that.

What is Access Reviews, really?

Access Reviews is a recurring “are you sure?” loop. You point it at a group, an application, a privileged role, or every guest in your tenant. On a schedule you pick, it emails a reviewer — you, the group owner, or the user themselves — and asks them to confirm whether each person still needs the access they’ve got.

If the reviewer says no, or doesn’t reply and you’ve configured “no response = deny”, the access gets removed automatically when the review ends. No tickets. No spreadsheet. No “I’ll get to it next quarter”.

It’s the same job your auditor wants you to do at a desktop level. Just done in the portal, on a timer, with an audit trail attached.

What you need to run one

Licensing trips most people up here. Access Reviews is an Entra ID P2 or Entra ID Governance feature, and licensing is per user, not per tenant. Every user whose access you’re reviewing needs to be covered. Guest accounts don’t need a license to be reviewed, which is the one bit of good news.

Business Premium customers don’t have P2 in the box. If they want this, they need Microsoft 365 E5 or the Entra ID Governance add-on. Tell the client up front — don’t promise the feature and discover the gap at invoice time.

You’ll want Identity Governance Administrator or Global Administrator to set the first review up. Group owners can run reviews on their own groups once an admin enables the toggle in the Access Reviews settings.

Step-by-Step: a recurring guest review

Start here on every tenant. It’s the easiest win.

Open the portal

Sign in to entra.microsoft.com as Identity Governance Administrator. Go to ID Governance > Access Reviews > New access review.

Pick what to review

In Select what to review, choose Teams + Groups, then All Microsoft 365 groups with guest users. This is the magic option. It creates one recurring review that sweeps every M365 group containing guests, across the whole tenant, automatically, forever.

Set Scope to Guest users only.

Pick your reviewers

Pick Group owners with a fallback. Group owners actually know whether Alice from the partner agency still needs Teams access. You don’t. You also don’t want to be reviewer-of-last-resort for fifty groups.

Set the schedule

Recurrence: Quarterly. Duration: 5 days. Long enough that nobody can claim they were on leave. Short enough that the next quarter doesn’t lap it.

Set the settings that actually matter

This is where most people skim and lose the whole value of the feature. Slow down.

• Auto-apply results to resource: On. Without this, denied users stay in the group until somebody manually clicks apply. They never do.
  

• If reviewers don’t respond: Remove access. Yes, really. If the owner can’t spend two minutes confirming a guest, the guest goes.
  

• Justification required: On. Forces reviewers to type a reason for “keep”. Stops the rubber-stamp click-through.
  

• Mail notifications + reminders: On.

Name it Quarterly Guest Review - All M365 Groups, hit Create, done.

Step-by-Step: privileged groups and admin roles

Same engine, different doorway. PIM for Entra roles and PIM for Groups each have their own access review entry point — not the one above.

For Entra admin roles

Open PIM > Microsoft Entra roles > Access reviews > New. Review every role with active or eligible assignments. Reviewer = the user themselves, because self-attestation forces them to type a justification. Add a second-stage approver if you want belt-and-braces. Recurrence: every 90 days for admin roles. No exceptions.

For privileged groups

If you’re using PIM for Groups to gate access to sensitive things, you can review the eligible members on the same cadence. Same wizard, hosted under PIM. Same settings. Same auto-apply.

Notice what’s missing? PowerShell. None of this needs it. Portal only.

One artefact you can paste into every client runbook

Guest access:     quarterly, 5-day window, owner-reviewed,
                  no response = remove, auto-apply on.
Admin roles:      every 90 days, self-attest + 2nd stage,
                  no response = remove, auto-apply on.
PIM for Groups:   every 90 days, owner-reviewed,
                  no response = remove, auto-apply on.

Notice what’s not in there? Anything called “annual”. Annual reviews don’t do anything except let stale access fester for eleven and a half months. If the cadence isn’t quarterly or better, you don’t have a control — you have a calendar reminder.

Why this actually changes behaviour

Before: “I’ll clean up guests when I get a chance.” After: “The system already did it last Tuesday.”

That’s the shift. Access Reviews moves access cleanup from a thing humans intend to do into a thing that happens whether they intend to or not.

For an MSP the win is bigger. Every client tenant you manage produces a quarterly evidence trail — who reviewed what, what got removed, who signed off. Exactly the evidence the cyber insurer asks for at renewal. Exactly the evidence an SMB1001 or Essential Eight auditor wants on the table. According to the Access Reviews FAQ, reviewers and decisions are captured against each instance, so the audit trail is already there — you just have to turn the reviews on.

You’re not selling “we’ll clean up your guests” anymore. You’re selling governance with a paper trail.

Access Reviews isn’t there to help you remember to remove stale access. It’s there to remove it whether you remember or not.

If you’re not turning this on for your clients, you’re leaving the easiest governance win in Microsoft 365 on the table.

Most MSPs I talk to have a Conditional Access policy that blocks “high-risk countries”. They built it once, switched it on, and never looked at it again.

Then they sleep well at night.

That’s the problem.

A country block on its own is theatre. The attacker is on a VPN egress inside a country you allow, or a residential proxy, or a mailbox client that already has a refresh token. Named locations are useful — but only if you understand what they actually do, and where they fall down.

What is a named location, really?

A named location is a label. That’s it.

You’re telling Entra ID, “this IP range is my office”, or “these countries are where my staff actually work”. The location doesn’t enforce anything on its own. It’s a building block you then reference inside a Conditional Access policy.

The policy does the work. You decide whether to block, require MFA, or skip a control. The location is just the where.

And here’s the bit that bites people. Location is evaluated after first-factor authentication. The password’s already gone. Conditional Access then decides what happens next. Treat named locations as a layer, not a perimeter.

Step-by-Step: Setting up a country block that actually earns its keep

Portal path only. Report-only first — non-negotiable.

Open Named locations

Sign in to the Microsoft Entra admin centre as a Conditional Access Administrator. Go to Protection > Conditional Access > Named locations.

Create a Countries location

Click + Countries location. Name it something obvious — “Allowed countries — AU only” beats “Country Block 1”. Pick the country (or countries) where your staff actually sign in. Tick Include unknown areas if you want the location to also catch IPs the geo-database can’t classify. I leave that off for allow-lists and on for block-lists. Save.

Create the policy

Go to Policies > New policy. Name it. Under Users, pick All users — then exclude your break-glass accounts. Always. Under Target resources, pick All resources.

Set the network condition

Under Network, set Configure to Yes. Include Any network or location, then under Exclude select Selected networks and locations and pick your “Allowed countries” entry. That gives you “block everything outside my country”.

Grant

Under Access controls > Grant, choose Block access.

Switch to Report-only and review

Set Enable policy to Report-only. Create. Then watch the sign-in logs for at least 48 hours. The report-only results tell you exactly which users would have been blocked. Anyone surprising in there? Investigate. Then flip the policy on.

Why this actually changes behaviour

Here’s the real win. Once you’ve got clean named locations, every other CA policy gets sharper.

The “skip MFA from a trusted location” pattern — careful with that. Marking your office public IP as trusted feels like a productivity gift to users. It’s also the exact thing an attacker on your guest Wi-Fi or a compromised contractor on your VPN will piggyback. My recommendation? Don’t mark anything as trusted unless you have a strong reason and you’ve documented it. Use sign-in frequency and authentication strength to soften MFA friction instead.

“But our staff hate MFA prompts in the office.” Then fix the prompts. Don’t punch a hole in the wall.

The other classic trap is the corporate VPN. If everyone egresses through one public IP in a country you’ve blocked, you’ve just locked your own staff out. Map your VPN exits before you write the policy. Read the network assignment conditions before you write the policy, not after.

Notice what’s missing from all of this? PowerShell. You don’t need it. The portal does the job, and the audit trail is clearer.

A country block doesn’t stop attackers. It thins the noise so the rest of your stack can do real work. If you’re not showing your clients this — and explaining why “trusted location” is a loaded word — you’re leaving security maturity on the table.

That’s the job. Use named locations for that, and not for the warm feeling a checkbox gave you.