Forum Discussion
What is your SOP for old risky users?
Recently have been tasked with leveraging Entra ID to it's full potential. We've a suite of different tools we use for alerting, so the Risky Users component was essentially ignored for a couple years, and there's a buildup of alerts for sign-in attempts I can't even pull logs for. These users would've been required to change their password since the date on most of these, and we have some hybrid environments I plan on enabling self-clearing for.
But wondering what other MSPs have done in this scenario?
This is a great process, but I am not sure how you are looking for old risky signing are you saving them in some storage? I guess Microsoft keep them for 90 days . I would suggest using access reviews and perform quarterly assessment which show access user activates if he has logged into the system or not if the user is a privilege user you can directly send email if they still need it or else remove the privilege access.
Most importantly if you find user who is high privileged and not logged for more than 60-90 days better remove his privileges and make him a normal user and then force him to reset the password, if still doesn't do then better disable it
For our tenants, Ms only keeps actual sign-in logs for 30 days. But we've inherited Tenants before that had user risk from years ago (presumably because no one understood Entra, which I can't blame them for). Can't validate what caused the risk. But we have a 3rd party service that scans various darkweb forums and db's and alerts us (sort of like haveibeenpwned, but for full domains)... I've been checking this, and often that risk lines up with a posting on darkweb. Either case, I'll check the most recent password change and validate it's not lingering. If I have darkweb info, I can usually get some of the password schema and get the user to completely redo it
Hi underQualifried,
In my case, for old risky users, I start by reviewing the historical alerts and identifying which users are still active and which ones aren’t. For those that are still active, I ensure they reset their passwords and update any compromised accounts. I also use Entra ID’s security policies to enforce additional authentication measures like MFA. For users who are no longer active or have no valid sign-ins, I consider disabling or deleting their accounts. If there are any hybrid environments involved, I enable self-clearing to make the process smoother and reduce the backlog of alerts.
Ultimately, the goal is to tighten security while cleaning up unnecessary risks from old accounts.
I hope it gives you some ideas!
Hi luchete thanks for the input... I think I've followed a similar process. Check Entra ID for "Account Enabled" or 365AC for "Sign-on Allowed" to rule out inactive accounts. For those active, I check the date of most recent password change - if this date is BEFORE the risk alert, I have them reset. If it's after, I don't force a reset. In either case, I check sign-in logs in Entra, and verify recent login details are as expected (IP/location/device are recognized, MFA passed, etc)... If the password reset occured AFTER the risk, I check that login and verify the details (to ensure it was really them resetting). Old accounts get set to sign-on disabled. We use Conditional Access for approved locations, MFA and the Entra P2 risk policies (though we're still testing these out)
Any of that stand out to you as bad practice, in your experience? I'm a little bit unsure about bothering someone with "your password was compromised 3 years ago". We're also rolling out DarkWeb scanning, so I'm just dealing with a lot of historical stuff right now, and trying to optimize the process. Thanks!Hey underQualifried,
Your process looks solid. The checks you’re doing around account activity, sign-in logs, and MFA are all good practices. One thing to consider is how you handle older accounts that were compromised a while ago. While notifying users about something from a few years ago might feel awkward, a simple message explaining the situation and encouraging them to check their security settings (like MFA) might be helpful without causing too much concern.
As for the password reset process, if the reset happened after a risk alert, an extra verification step could give you more confidence in the user’s identity. In my opinion that should be enough.
You're on the right track overall 👌
