Microsoft Entra ID Protection - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Microsoft says more than ninety seven percent of identity attacks are just password attacks. The usual way into a Microsoft three hundred sixty five account is a password that leaked somewhere else. Not a clever hack. Microsoft Enter ID protection is the part of Microsoft's cloud that watches those sign ins and flags the accounts that look stolen. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. It doesn't lock everyone out because it scores the risk and then asks the person to prove it's really them. By the end, you'll know how that score works, what clears it, and whether you already have it turned on. What identity protection actually watches.

0:41 Start with the sign in because that is where everything begins. Every time you open Teams or Outlook or SharePoint, you sign in through a service called Microsoft Entra ID, and that service is what checks who you are. For most companies, entra ID is the front door to email files, chat, and every app built on top of Microsoft three hundred sixty five. If you have seen the name Azure Active Directory. In older training material, it's the same service with a newer label. Entry ID protection sits on top of those sign ins and watches how they behave. Microsoft describes it as a way to detect, investigate, and fix identity based risks, and it can pass what it finds to other tools that make access decisions. It watches what happens after the sign in two, because some trouble only becomes visible once the session is already open. The score it builds from all of this is the thread that ties the rest of this together.

1:26 Attackers like identity for a simple reason. Breaking into a network is hard, and logging in with a stolen password is easy. Microsoft puts it bluntly when it says that adversaries aren't breaking in, they're signing in. Now, here's where the scale matters. Microsoft analyzes trillions of signals a day pulled from Active Directory, from Microsoft accounts, and even from gaming on Xbox. It also sorts through thirty eight million identity risk detections every day, which is a useful reminder that this is not a rare event. That wide net is why the system can tell a normal sign in from a strange one, because it has seen so many normal sign ins that it knows what your normal looks like. The things it flags are more varied than you might guess. One is a sign in from an anonymous IP address, the kind someone uses to hide where they are. Another is a password spray attack, where an attacker tries one common password across thousands of accounts at once.

2:10 A third is a leaked credential, meaning a username and password that already turned up in a breach. The list runs well past those. Hold on to this one detail. During every single sign in entry ID protection runs its real time checks and produces a risk level for that attempt. The score belongs to that one attempt to get in, not to the whole day or week. Picture it less as a firewall, scanning traffic, and more as a system asking one human question, which is whether this sign in matches how this person usually behaves. Two kinds of risk the user and the sign in. This is the part that catches people out. You might think a risky login and a risky account are the same thing, but enter ID protection is actually asking two different questions, and blending them is easy. The first is sign in risk, which is the chance that one specific sign in isn't the real account owner.

2:52 It's about a single moment, one attempt to log in and nothing else. The second is user risk, meaning the account itself may be compromised, that someone has the keys and can come back whenever they want. This one's about the person, not about one login. There's a reason to keep the two apart and it comes down to the fix. A risky sign in is usually handled right there with the second check. While a risky account often needs a password change because the password itself may already be out there. A quick example makes the split click if your account suddenly signs in from a country you have never visited at three in the morning, that's sign in risk. If that same account also shows up with a password that was found in a data breach, that's user risk because the credentials themselves are in someone else's hands. Microsoft ties the two together with one simple rule a user becomes a risky user when they have one or more risky sign ins, or one or more risks detected on their account.

3:38 Either path lands them on the same list that an admin can see. Here is a connection worth noticing. A sign in risk that nobody clears can roll up and add to the user's risk, so a single odd login can slowly turn into a flagged account. The two measures feed each other in the reports, which is why a person can look risky even when the last few sign ins seemed fine. Timing matters here too, and it explains something that confuses people. Some checks run while the sign in is happening, and the details appear in the reports within five to ten minutes. Other checks run after the fact, and they can take up to forty eight hours to show up. Those slower checks look at the bigger picture, which is why a risk level can change a day later. What the risk levels mean once the checks run, they produce a score and that score comes in three levels low, medium and high.

4:20 That's the whole scale. The plain English version goes like this. High risk means Microsoft is highly confident that the account is compromised. Medium risk means there are moderate signs of trouble, but less confidence that someone else is really in there. Low risk means something looked off and the confidence is lower still. Those levels come from machine learning that estimates how likely it is that a person's credentials are known to someone who shouldn't have them. Along with the level, Microsoft keeps a risk detail, which is the plain language reason behind the score. It lets an admin see whether the risk came from a leaked password, a spray attack or something the person reported themselves. Not every detection sits at one fixed level unfamiliar sign in properties, for example, can fire at high, medium, or low, depending on how unusual that sign in looks next to the person's history.

5:02 The stranger it looks, the higher it climbs. Some detections are always high because Microsoft isn't guessing leaked credentials and a verified threat actor IP both land at high risk because in those cases, there's real proof that something was exposed or that a known attacker is involved. There's one more detail that rarely makes it into beginner explanations, and it matters for expectations. Low risk items age out on their own after about six months, which keeps the report clean, medium and high risk. Don't age out and they sit there until someone fixes them or dismisses them. A level is really a confidence reading, which means a low score can still be worth a look, and a high score can occasionally be a false alarm that an admin clears. The level matters for two reasons at once, because it decides how urgently a person should look and how strict the automatic response is allowed to be.

5:44 How risk turns into a decision. A score on its own does nothing. It has to turn into a decision. And that decision is where the whole concept pays off. The score gets handed to Microsoft Entra conditional access if that name is new. Think of conditional access as a set of. If this, then that rules for signing in. When a condition is true, a rule fires. Two of those conditions come straight from. Enter ID protection and their sign in risk and user risk during every sign in the protection layer sends the detected levels over and the rules get evaluated. Each policy can be set to trigger at low, medium, high or no risk detected, so an organization tunes the strictness to its own comfort level. A cautious company might challenge a medium risk sign in, while a more relaxed one waits for high from the person's side, it looks like a normal prompt.

6:27 They don't get a security lecture, they just have to prove it's them. For sign in risk, the choices are easy to follow. The rule can block the sign in, allow it require multifactor authentication, or require the person to sign in again. If the person completes the required step, like a prompt on their phone, the risk clears on the spot. For user risk, the choices are require risk remediation, require a password change, or block access. Those three aim at a different problem because user risk means the account itself may be in the wrong hands. The middle option require risk remediation is the clever one, and it deserves a plain explanation. It adapts to how the person signs in. If they use a password, it asks for a secure password change and then cuts off their old sessions. If they sign in without a password, it cuts off the sessions and asks them to sign in again. One policy different fix chosen automatically.

7:09 This is where automation earns its keep at the scale Microsoft operates. No team could review every sign in by hand, so the rules handle the common cases and leave only the strange ones for a person. There's a rule about stacking these that keeps admins out of trouble. Risk remediation beats a password change and block beats everything else. Don't pile several of these onto the same person because only the strongest one wins and the rest go to waste. One honest limitation is worth knowing. The full risk remediation flow doesn't work for guests and external users, because Microsoft doesn't revoke sessions for those accounts the same way how people fix it themselves. Now we get to the part beginners like best. Most of the time, nobody from it has to get involved because the person clears the risk on their own. Microsoft calls the self remediation, and it's exactly as simple as it sounds.

7:51 If it's sign in risk, the person gets prompted for multi-factor authentication. That's the second proof we keep coming back to. Usually a code or an approval on a phone. Once they pass it, the risk state flips from at risk to remediated, and they carry on with their day. If it's user risk and the policy asks for a password change, the person completes multi-factor authentication and then sets a new password. The risk clears and their old sessions get cut off, so anyone holding the old password is locked out, too. There's one honest nuance here because people mix these two up. This is a secure password change where the person still knows their current password and simply replaces it. It isn't the same as a forgotten password reset, and it only works if the person already registered a second factor, which is why setting that up ahead of time matters so much.

8:32 Sometimes the system clears the risk all by itself if the person provides a second factor, or if a later check decides the sign in is no longer risky, the risk gets dismissed automatically and stops counting against them. When it can't be cleared, an admin steps in. They can issue a temporary password, require a password change, dismiss the risk, confirm that the account is compromised or unblocked the person. A temporary password brings the account back to a safe state right away, with the catch that the person has to be told what it is. Hybrid users aren't left out either. If your organization keeps accounts on an on premises server as well as in the cloud, one more setting matters with password hash synchronization switched on, a password change made on a company device can clear the user's risk to. The whole point of this design is to take load off the help desk.

9:13 A person who can fix their own risk is one fewer ticket and one faster fix. There's also a safety net underneath all of this. Microsoft automatically blocks sign ins that carry very high confidence of being risky, most often from old style sign in methods that skip modern protections. That's one more reason to move away from those older methods. What the admin actually sees when something can't be cleared automatically, it lands in front of a human and the reports are built for that moment. There are three main reports. Risk detection shows each individual thing that was noticed. Risky sign ins shows sign ins that carry one or more of those detections. Risky users shows the accounts because a user gets flagged when they have a risky sign in or a detection on their account, and admin starts by looking at the dashboard and the reports, then checks the sign in logs for other accounts with the same fingerprint.

9:56 If five accounts all failed from the same IP address in the same hour, that pattern matters far more than any single event. Then comes the judgment call at the center of the whole job, which is deciding whether the alert is real. An admin can confirm a sign in is compromised, confirm it as safe, or dismiss it as a true positive that turned out harmless. The difference between those last two is small but real. Confirming safe tells the system this was a false alarm. While dismissing says the alert was real but harmless. The way a planned security test looks suspicious without being an attack. The details pane is where the story fills in. It shows the app the person was reaching for the device, the location, and the IP address, which is usually enough to separate a real attack from a false alarm. For bigger teams, the reports can be exported or read through an API so the data can flow into a security tool the company already uses.

10:42 If an admin confirms that an account is compromised, there's a short list of moves. Reset the password. Block the account. Revoke the tokens that keep the session alive, and disable a compromised device. Revoking sessions is the step people forget, and it's often the one that actually pushes an attacker out. The reports don't keep everything forever, so expectations should match risky sign ins. Go back thirty days and risk detections go back ninety days. This is also a controlled job, not a free for all. A security reader can look without changing anything. A security operator can act on risks and changing the policies. Needs a security administrator or a conditional access administrator. What it costs and what you need before any of this matters to you. There's one practical question to settle, which is whether you actually have it. Now for the practical part.

11:23 Full entry ID protection needs a license called Microsoft entry ID P two. And that single requirement is what trips people up without P two. You aren't completely blind, but you're limited in the free and P1 versions. Only medium and high risk users even show up, and there's no details panel and no risk history to dig through. You also can't turn the risk policies on at all, and detections show up as a vague additional risk detected with no detail behind them. So here's the sentence to remember about the two paid tiers. Conditional access itself comes with P1, but the risk based version of it needs P2. That single distinction explains most of the confusion. P1 does give you conditional access and multi-factor authentication, but it doesn't give you the risk engine underneath them, and that engine is the reason the feature exists.

12:03 The good news is that plenty of workplaces already have this, and nobody realizes. Entry ID two ships with Microsoft three. Sixty five E5 The Microsoft Defender Suite Enterprise Mobility Plus Security E5, and the entry suite, which folds in several other identity products along with it. The lighter tier entry ID, P1 ships with Microsoft three hundred sixty five, E3, and Business Premium. If your company runs on one of those plans, the feature may already be sitting there, paid for, and switched off. There's one caveat about detections. Some of them come from other Microsoft Defender products, so those specific signals only appear if you also have the matching license. An empty report doesn't always mean everything is fine. There's also a note for the future facing crowd. The newer reporting covers risky agents, too, because AI agents now sign in and hold access, just like people do.

12:48 Best practices that actually matter. If you take only a handful of setup steps away from this, make them these. The one that prevents disaster comes first. Exclude your emergency accounts and keep a break glass account that these policies never touch. So a misconfiguration can't lock everyone out of the building at once. Service accounts deserve the same care. Next, get people registered for multi-factor authentication before they need it. Self remediation depends on the person already having a second factor set up. So the MFA registration policy isn't optional. It's the foundation everything else stands on. Then mark your trusted locations. When you tell the system which networks and VPN ranges are known and safe, sign ins from those places lower a person's risk and cut down on false alarms.

13:28 That step isn't just a convenience either, because it teaches the system what a safe signing looks like and sharpens every judgment it makes afterward. Before you enforce anything, use report only mode. It shows you exactly what a policy would have done before you switch it on and start blocking real people. When you do enforce, start small. Scope a new policy to a test group. Watch how it behaves for a week and widen it out once you trust it. Turn on the notifications to ask for an alert when a user gets flagged and a weekly digest. So risk doesn't sit unseen in a report and nobody opens. And before any of that review the existing reports. If there are already flagged users, you want to know that before you turn on enforcement and then wonder why half the company is being blocked, if you can simulate a threat during testing so your team has practiced the response before it counts.

14:11 A quick recap and one question. So let's bring it together. Enter ID protection which is how people sign in. It scores user risk and sign in risk as low, medium or high. It hands that score to conditional access, which decides whether to allow the sign in, block it, or ask for proof. In most cases, people clear the risk themselves with a second check or a secure password change, and anything left over goes to an admin who investigates and acts. Here's the question I'll leave you with. If a stolen password is the most common way in, and the second check stops nearly all of it, why is a password on its own still the default in so many places?