Let’s talk about a feature in Entra ID that doesn’t get nearly enough spotlight, Protected Actions. Think of them as the “Are you sure you want to do that?” moments for your tenant. They’re built to stop high-stakes changes from happening too easily whether it’s an honest mistake or something more malicious. In short, they help keep your environment safe from both accidents and bad actors who might be poking around where they shouldn’t.
They’re like a seatbelt for your admin controls: you hope you never need them, but you’ll be glad they’re there when things go sideways.
A Smokin’ Good Cautionary Tale
Story time! So, picture this: I’m outside, the smoker is rolling, and I’m just about ready to pull off a glorious smoked meatloaf. (Yes, you can smoke a meatloaf. Yes, you should smoke a meatloaf. Go ahead and try it, I’ll wait.)
Anyway, just as that glorious loaf was about to reach peak deliciousness, I got the call. Admins were being kicked out of Azure, Intune, Exchange you name it. Turns out someone had tweaked a Conditional Access policy without fully thinking it through, and now the very people who manage the environment couldn’t get in.
By the time I joined the call, someone was already sharing their screen with the Conditional Access policies up. I took one look, sorted by modified date, and rolled things back. Disaster averted. And yes, in case you’re wondering: the meatloaf survived. It was glorious.
So, Where Do Protected Actions Fit Into This?
Now, would Protected Actions have stopped this scenario completely? Maybe not. But they could have added a speed bump like requiring reauthentication or MFA before making that risky change. That little pause might’ve been just enough to make the admin think twice.
Let me show you how you can set these up. It’s super simple.
Step 1: Create an Authentication Context
Start by heading into Entra and creating a new Authentication Context.
I named mine Force Reauthentication because sometimes, you need to make people prove they’re really them.
Step 2: Build Your Conditional Access Policy
Next, create a new Conditional Access policy. The key part here is linking it to your new Authentication Context under Target Resources.
Also, under Session Controls, set the Sign-In Frequency to Every Time.
Step 3: Add Some Protected Actions
Now navigate over to Roles & Admins → Protected Actions and hit the “Add Protected Actions” button.
Select the Force Reauthentication context, then click on Select Permissions.
There’s a lot to choose from here cross-tenant configs, B2B settings, but for this walk-through, I will stick with Conditional Access permissions. For a full list see this link.
Add the ones you want and hit Save.
Step 4: Try It Out!
Go ahead and try creating a new Conditional Access policy. You’ll get prompted to reauthenticate. That’s Protected Actions doing their thing.
Thinking like a bad actor? Try editing an existing policy to sneak around some rules. Guess what? Protected Actions still have your back.
Final Thoughts
Protected Actions and Authentication Contexts aren’t just about security, they’re about giving your environment a chance to breathe before someone makes a major change. You can use them to require stronger auth, compliant devices, and more. Seriously, go explore what else they can do. Your future self will thank you.
….. and yes, so will your meatloaf.
