Threatscape’s award-winning Microsoft Security Practice has conducted hundreds of security assessments, and we’ve recommended Microsoft Entra ID in almost every one. It’s an incredibly powerful tool that gives security teams granular control over their identity and access policies to maximise protection and get the most out of their Microsoft Security licence capabilities.
With that said, Entra ID is vast. And it never stays still. There’s a wealth of opportunities for misunderstandings and misconfigurations.
We’ve pulled together five of the common Entra ID strategy mistakes that we encounter, with guidance on how you can avoid these pitfalls within your own tenant.
Mistake 1 - Misconfiguring Conditional Access Policies
The first mistake is a misunderstanding of exactly how Conditional Access policies should be configured, specifically in the case of sign-in risk, and user risk versus sign-in risk. Understanding how these two settings interact within your policies will ensure they’re operating properly and giving you the protection you expect.
It may not be immediately apparent, but when creating Conditional Access policies based on sign-in risk, keep in mind that selecting a specific risk level only applies to that exact level—not any higher ones. The risk checkboxes work as “equal to,” and not “greater than or equal to,” so you’ll need to manually select all the levels you want to cover for complete protection.
Additionally, when including both user risk and sign-in risk in the same policy, both conditions must be met simultaneously for the policy to be effective—it’s not an either/or situation. If this isn’t your intention, it may be better to create separate policies for user and sign-in risk to ensure that they both operate effectively.
Mistake 2 – Requiring Password Resets for Passwordless Users
To secure high-risk users, you can opt to require a password change within Grants. While this requires MFA and provides the associated protection, it’s worth considering the implications of necessitating a password change specifically if the user in question has previously transitioned to passwordless access.
But there are solutions, provided you’re specific about which policies you want to apply to which groups. Instead of requiring a password change, consider blocking authentication for high-risk users to prompt clearer action on-screen. You can also choose to exclude passwordless users from policies that require a password change. Ultimately, it’s about tailoring your policies to your users, and their specific needs.
Mistake 3 – Adopting a One-Size-Fits-All Approach
There’s no need to apply the exact same policy, at the exact same strength, to all users. Different groups will have different security needs, based on their access level, risk profile, and privilege within your estate. When rolling out new policies, being heavy handed in your application is likely to generate an unmanageable level of false positives and create issues in adoption.
Instead, narrow your scope, take advantage of user groups, and consider trialling stricter policies for VIPs and global admins, and work from there until you’ve created an access security strategy that you’re happy with.
Mistake 4 – Excluding Guest Users from ID Protection
Don’t automatically assume that you should exclude guest users from identity protection policies. While security teams may rationalise that an overzealous approach to guest security is likely to negatively impact productivity, particularly when controlling a guest’s own Entra ID isn’t possible, ultimately, guests and their devices bring specific risks with them that shouldn’t be dismissed.
If anything, consider applying even more stringent identity protection policies to guest users to mitigate potential vulnerabilities associated with their access. It’s an approach that will need attention to detail, and can’t be applied in broad strokes, but for maintaining security, it’s often worth the time and effort.
Mistake 5 – Overlooking Audit Log Retention
As with the majority of Microsoft 365 Security tools, what you get is dependent on the licence you hold. In the case of Entra ID log retention, retention time varies by licence level, with the Free Level retaining 7 days, P1 retaining 30 days, and P2 retaining 90 days. It’s also worth noting that upgrading your licence does not retroactively extend log data retention, and crucially, vital historical data could be unavailable for investigations if not retained beforehand. Should you experience an incident and then purchase a higher licence tier to gather more data, unfortunately, it’s unlikely to be any help.
To prepare yourself for audit and investigation, understand your licence’s log retention limitations, take proactive steps to safeguard essential data, and consider exporting log data to external tools like Log Analytics or Microsoft Sentinel to retain information beyond the default retention periods.
The Microsoft 365 Security suite is an extremely comprehensive tool set and managing it can be difficult. Entra ID is no different.
Threatscape’s complimentary Microsoft Entra ID Advisory Service helps you understand the identity threats we see lodged against organisations every day, and the associated security protections available within your Microsoft 365 licence. During your no-obligation consultation with one of our Microsoft security experts, you’ll gain insight and recommendations on how Entra ID and other capabilities within Microsoft 365 help defend cloud identities against a wealth of threats.
