Most organisations have an IAM process in place. Onboarding, offboarding, the joiner-mover-leaver cycle. Employees come in through the HR system, flow through the IAM tool, and end up in Entra ID. Everything feels under control.

But identity blind spots still emerge, even in well-governed environments. And they tend to follow the same patterns.

In this article:

• How identity blind spots build up over time

  • Inactive and orphaned accounts

  • Excessive privileged access

  • Incomplete MFA enforcement

  • Over-privileged applications and service principals

• Together, they expand the attack surface

• What to do about it

• Frequently asked questions

How identity blind spots build up over time

The root cause is straightforward. Most organisations have solid control over the identities that flow through their formal IAM processes: employees entering through HR systems, standard user accounts governed by conditional access policies, and perhaps a handful of applications with designated owners.

But not everything follows that process.

Admin accounts are often dealt with manually. External contractors may not be fully governed. Test accounts linger long after the project that created them has ended. Agents and service principals are created for integrations, migrations, and testing, then forgotten. Old accounts synced from on-premises Active Directory during a migration to Entra ID are never cleaned up.

These all end up in your Entra environment, but outside your formal identity governance processes. They are not covered by your joiner-mover-leaver cycle. They do not show up in your standard reports. And over time, they accumulate.

That accumulation is where the blind spots begin. Based on what we see across hundreds of identity environments, four categories show up consistently.

1. Inactive and orphaned accounts in Entra ID

These are accounts that are enabled, hold access, and have not signed in recently. We use 90 days as the threshold for categorising an account as inactive, but many have been dormant far longer.

The numbers are consistent: somewhere between 20 and 40 per cent of accounts in a typical Entra ID environment are inactive. That includes member accounts, resource accounts, and guest accounts that were given access to parts of your data and never revoked.

Why does it matter? Most of these accounts have no clear owner. That is precisely why they still exist. No one is responsible for them, and no one is watching them. They do not appear in your day-to-day monitoring because they sit outside the processes you are actively managing.

If one of these accounts is compromised, it can be difficult to detect. It is just an existing account in your environment that suddenly starts being used. There is nothing in your standard monitoring to catch it, because the account was never flagged as something to watch.

There is also a direct cost impact. Many inactive accounts still hold licences you are paying for. The security risk and the financial waste are two sides of the same problem.

Inactive accounts are the simplest blind spot to categorise, and often the easiest place to start. Learn more about how Bsure surfaces inactive identities.

2. Excessive privileged access in Entra ID

This is about admin accounts that hold permanent roles, often more than they need, and often assigned in ways that increase risk.

Common patterns include:

Global admin roles used for day-to-day operations. Even when the tenant is licensed for Privileged Identity Management (PIM) and eligible roles, we regularly see permanent global admin assignments used out of convenience. Roles are assigned "just in case" rather than based on actual operational needs.

Admin roles assigned to normal user accounts. This means the same account used for email, Teams, and daily work also has admin privileges. If that account is compromised, the attacker does not just get access to the user's data. They get admin-level access to the entire environment.

Admin accounts synced from on-premises Active Directory. This is a particularly risky pattern. If the on-prem account is compromised, the attacker has a direct path to pivot into the cloud as an admin. Microsoft's own zero trust guidance explicitly recommends against this.

Orphaned admin roles. Old partners, former consultants, previous employees whose separate admin accounts were simply forgotten. Even legacy Entra Connect sync service accounts that were given roles years ago and no longer need them.

One compromised admin account is enough. The blast radius is your entire environment. This is the blind spot we would prioritise addressing first.

3. Incomplete MFA enforcement

MFA is often treated as a binary: either you have it or you do not. The reality of MFA enforcement in most Entra ID environments is more nuanced.

Conditional access policy gaps. The policies that enforce MFA often have exclusions that made sense years ago but no longer align with zero trust principles. A common example: excluding the office network from MFA requirements. That was standard practice a few years back. Today, it creates a gap that attackers can exploit.

Uncontrolled MFA registration. Users need to register their MFA methods before they can use them. If your environment allows MFA registration from anywhere using only a username and password, you have a problem. You do not know whether the person registering is the real user or someone who obtained their credentials through a password leak. A conditional access policy for security information registration, combined with temporary access passes, closes this gap.

Weak MFA methods. Not all methods are equally strong. Push notifications, SMS, and voice are phishable. FIDO2 keys and passkeys are phishing-resistant. For admin accounts in particular, phishing-resistant MFA should be the baseline.

According to Microsoft's Digital Defense Report 2025, 97% of identity attacks target credentials, accounts, and access. Without an MFA challenge, a password spray or a leaked credential is all an attacker needs to sign in. With weaker MFA methods, adversary-in-the-middle techniques can intercept the session and grant the attacker persistence.

4. Over-privileged applications and service principals

This is arguably the fastest-growing identity blind spot, and the one where many organisations have the least control.

Service principals and enterprise applications accumulate broad permissions over time across Microsoft Graph, SharePoint Online, and Exchange Online. They are created for migrations, integrations, backups, and testing. When the project ends, the application stays, often with the same permissions it was given on day one.

Consider a common scenario: an organisation migrates from SharePoint on-premises to SharePoint Online. The migration tool is granted full permissions on SharePoint Online. Years later, the application still exists in Entra ID with those same permissions, because no one owns the lifecycle of that application type.

Vendors frequently use secrets rather than certificates to authenticate their applications. A secret is essentially a password. Between the vendor and your data sits a single string. Organisations should challenge their vendors to support certificate-based authentication instead.

The ownership problem is significant. Enterprise applications used for single sign-on very often have no clear owner. When an application appears without an owner, it should be investigated. Applications are an increasingly common path for attackers to gain persistence and escalate privileges in cloud environments.

There are two main attack vectors. First, tricking a user or admin into approving a rogue application that has enough permissions to give the attacker access. Second, compromising a user who happens to own an application with elevated permissions, then using that application as a path to broader access.

Together, they create an unnecessarily large attack surface

Individually, each of these blind spots represents a manageable risk. Together, they create an attack surface that is larger than it needs to be.

Orphaned accounts with lingering access. Admin roles no one is monitoring. MFA gaps that leave the door open. Applications with broad permissions and no lifecycle management. These are not exotic vulnerabilities. They are the everyday gaps that accumulate in any identity environment over time, particularly those that fall outside your formal IAM processes.

The common thread is visibility. These blind spots persist because they sit outside what most identity governance tools are built to surface. The accounts, roles, and applications are technically present in your Entra ID tenant. But they are not visible to the people and processes that should be managing them.

What to do about it

Seeing the problem is the first step. But visibility alone does not solve it, because in most organisations, IT is the only team that can see these gaps. The managers, business unit leaders, and application owners who are responsible for users, budgets, and operations do not have access to the data they need to act.

That is the topic of our next session: how to distribute identity governance across the organisation so that the people responsible can actually see what they are accountable for.

Next webinar: 13 May 2026, 15:00 CEST. Register here.

Learn more about how Bsure helps organisations gain visibility into their identity environment.

Frequently asked questions

• What are identity blind spots?
  Identity blind spots are gaps in your Entra ID environment that sit outside your formal IAM processes. They include inactive accounts, excessive admin privileges, incomplete MFA enforcement, and over-privileged applications. They are called blind spots because they exist in your environment but are not visible through your standard monitoring and governance workflows.
  
  

• How many inactive accounts are normal in an Entra ID environment?
  Based on what we see across hundreds of environments, somewhere between 20 and 40 per cent of accounts are typically inactive (defined as not having signed in for 90 days or more). This includes member accounts, resource accounts, and guest accounts.
  
  

• Why is MFA not enough to prevent identity attacks?
  MFA significantly reduces risk, but its effectiveness depends on how it is enforced. Gaps in conditional access policies, uncontrolled MFA registration, and the use of phishable methods (like SMS or push notifications) all create openings. Phishing-resistant methods like FIDO2 and passkeys provide stronger protection, particularly for privileged accounts.
  
  

• What is the risk of over-privileged service principals?
  Service principals with broad permissions can be exploited by attackers to gain persistence and escalate privileges. If an application has access to Microsoft Graph, SharePoint, or Exchange with broad permissions and no clear owner, it represents a significant and often unmonitored attack vector.
  
  

This article is based on a live session hosted by Olav Helland, Co-founder and Cloud Architect at Bsure. With 25 years of experience across Microsoft environments, Olav works with identity governance across hundreds of M365 tenants, from identity and access to the operational realities of running Entra ID at scale. Connect with Olav on LinkedIn.