Entra ID Password Protection + Smart Lockout

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.

Certificate-Based Authentication for SharePoint Online: The Bit Everyone Avoids

There’s a point every SharePoint admin eventually hits.

The script works.
The logic is solid.
But it still needs a username.

And that’s where it falls apart.

Because anything that relies on a human login isn’t automation. It’s just a task waiting to break the moment MFA tightens, conditional access changes, or the account gets locked.

Certificate-based authentication fixes that. It has for years.

The problem hasn’t been what to do.
It’s been how much effort it takes to do it properly.

The Problem Isn’t Authentication. It’s Assembly.

If you’ve ever set this up manually, you’ll know the sequence:

Create or import a certificate
Register an app in Entra ID
Assign API permissions like Sites.FullControl.All
Upload the certificate
Grant admin consent
Capture the thumbprint
Wire it all into your PowerShell scripts

None of it is particularly hard.

But it’s fragmented, fiddly, and very easy to get wrong.

Which is why most environments quietly fall back to interactive sign-ins… right up until they stop working.

What This Approach Actually Does

I’ve been written a new script —

https://github.com/directorcia/Office365/blob/master/o365-connect-spo-cert.ps1

with full documentation here – https://github.com/directorcia/Office365/wiki/Certificate-based-authentication-for-SharePoint-Online

The script behind this approach is designed to remove that friction.

Instead of documenting the steps, it executes them.

At a high level, it runs in one of two modes:

1. Generate Everything Locally

-GenerateLocalCertificate

This builds the foundation:

Creates a local certificate (optionally exports a PFX)
Can provision an Entra app automatically
Assigns required permissions (including SharePoint and Graph)
Prepares everything needed for ongoing use

It effectively handles the “setup once” phase.

2. Use Certificate Authentication

-UseCertificateAuth

This is the day-to-day mode:

Connects to SharePoint Online using the app and certificate
No username
No password
No MFA prompt
No interaction required

Just a clean, repeatable connection into the SharePoint admin endpoint. [github.com]

Why This Matters More Than It Looks

At face value, this is just authentication.

In reality, it’s capability.

Once your connection is non-interactive, a whole class of work becomes possible:

Scheduled SharePoint reporting
Overnight clean-up jobs
Site lifecycle management
External sharing audits
Compliance checks

All the tasks that were “nice ideas” suddenly become operational.

Because they no longer depend on someone being present.

That’s the real shift.

The Security Side (That People Miss)

There’s also a security upside that often gets overlooked.

Certificate-based authentication:

Removes passwords from scripts entirely
Reduces exposure to phishing and credential theft
Uses a service principal instead of a human identity
Allows tighter, scoped permissions (like Sites.Selected)

In short, it’s both more secure and more predictable than traditional login methods.

The Gotcha Everyone Hits Once

If you build this from scratch, you’ll probably hit the same issue most people do:

It doesn’t work immediately.

Not because it’s broken — but because permissions need time to propagate across Entra ID and SharePoint.

That delay is normal.

It’s also the main reason people abandon setups halfway through and revert to “just use an account”.

Where This Fits for MSPs

If you’re managing multiple tenants, this becomes even more valuable.

The pattern is simple:

One script
One certificate per tenant
One app registration per workload (or per tenant, depending on your model)
Store the mapping once
Reuse it everywhere

From there, your tooling becomes predictable.

No credential prompts.
No dependence on admin accounts.
No surprises when security policies tighten.

The Bottom Line

Certificate-based authentication isn’t new.

It’s just been inconvenient.

What this approach does is remove the inconvenience.

And once you do that, you start using it everywhere.

Because the real benefit isn’t the connection.

It’s everything that becomes possible after it.

Source material

The Quiet Productivity Cost of Watching AI Work

I noticed something a few weeks back during a busy Friday afternoon. I’d asked Copilot in Word to pull together a draft summary of a long client document, and instead of moving on to the next thing on my list, I just sat there. Watching. Cursor blinking. Sentences slowly stitching themselves across the screen like I was waiting for a kettle to boil. It took me a good thirty seconds to realise I was, in effect, staring at a digital pot — and getting absolutely nothing else done while I did it.

That small moment has stuck with me. Because I don’t think I’m the only one doing it.

The watching trap

There’s a quiet productivity tax that nobody really warned us about with generative AI inside Microsoft 365. We’ve been told these tools save us hours. And they will — but only if we actually use those hours. The moment we anchor ourselves to the screen and watch Copilot draft a reply in Outlook, summarise a meeting recording in Teams, or build out a deck slide by slide in PowerPoint, we hand back every minute of the gain.

I think this happens because the output feels unfinished until it’s done. The brain treats it a bit like a conversation — and you don’t walk away from someone mid-sentence. But Copilot isn’t speaking to you. It’s working for you. And it doesn’t care whether you’re in the room.

The result is a strange new flavour of busywork. You look productive. You’re sitting at your desk, focused, eyes on the screen. But the actual output of your time is whatever Copilot was going to produce anyway. You’ve added nothing. You’ve just supervised a process that didn’t need supervising.

Why staring at it doesn’t help

The other problem with the watching habit is that it isn’t even useful. You can’t speed Copilot up by looking at it harder. You’re not catching errors in real time, because most of us don’t read carefully enough mid-generation to spot a problem — and you’ll review the final output once it’s done anyway. The watching is pure overhead.

Worse, it primes a passive mindset. When you sit and observe the machine doing the work, you start to mentally check out. The next task on your list feels heavier than it should. You lose the rhythm of context-switching that real knowledge work depends on. By the time the draft email or summary lands, you’ve already half-disengaged. So instead of pouncing on it, reviewing it sharply, and sending it on its way, you take another minute or two to gather yourself.

That’s two layers of cost. The time you spent watching, and the time it takes to mentally re-enter the work.

Treat Copilot like a colleague, not a performance

The shift I’ve had to make is treating Copilot the same way I’d treat anyone I’ve delegated something to. You don’t stand over a colleague’s shoulder while they write a document. You hand it off, you go do something else, and you come back to review when it’s ready.

So when I ask Copilot in Excel to analyse a dataset, I switch to my inbox and clear a few replies. When I have Copilot in Word drafting something substantial, I move into Teams and respond to chats. When a deck is being assembled in PowerPoint, I’m reviewing tomorrow’s calendar or skimming a SharePoint document I’d been putting off. The five or ten seconds of context-switch cost is well worth the two or three minutes I would have otherwise stared away.

The deeper habit, though, is queueing the work. I now line up several AI-assisted tasks at once. A summary running here, a draft being produced there, an analysis underway in another window. Copilot is happy to run in parallel across Microsoft 365. There’s no good reason to make those tasks sequential by tying each one to your eyeballs.

What I’m watching next

The thing I’m paying attention to from here is how teams handle this collectively. Because once AI is doing more of the small tasks across an organisation, the productivity ceiling stops being defined by what the tools can do and starts being defined by what their humans do while the tools work. The businesses that win the Copilot game won’t be the ones with the best prompts. They’ll be the ones whose people have stopped sitting and watching, and started filling that reclaimed time with thinking, deciding, and acting.

The technology is doing its part. The next move is ours.