If you rely on Microsoft’s out-of-the-box role-based access control for Microsoft 365, your organization could be wide open to accidental breaches, insider threats, and compliance failures. This post breaks down why native RBAC is not enough, reveals hidden access risks inside your M365 tenant, and shows how to lock down your environment with least-privilege best practices and smarter, granular RBAC.
This article covers:
Role-based access control (RBAC) is a foundational access-management model that ensures users only get the permissions they need, for the period of time they need them (not in perpetuity). In the context of Microsoft 365, improperly scoped admin roles and overprivileged accounts are one of the leading causes of breaches and insider risk.
Native Microsoft 365 delegation tools may work for small tenants but often fail in large, distributed enterprises. This blog explores why RBAC matters, the real dangers of neglecting least-privilege, how Microsoft’s out-of-the-box model falls short, and how tools like CoreView enable truly effective, granular RBAC with delegation, auditability and least-privilege enforcement for greater M365 tenant resilience and security.
Role-based access control (RBAC) in Microsoft 365 is designed to shield your organization from the dangers of handing out too much access to too many people. But if you’re relying solely on Microsoft’s native RBAC tools to manage permissions, you probably do not have enough granularity in your access management, which is how breaches happen.
Overprivileged accounts, lingering admin rights, and unchecked role sprawl can turn your M365 environment into a ticking time bomb. With Microsoft 365, which is much more than a single app – spanning your entire business, including email, collaboration, identity, device management, SaaS apps, external guests, and global admin roles, RBAC is not optional. But standard Microsoft RBAC is also not enough, you are dealing with a problem that means a single wrong click or a compromised credential can give attackers or careless insiders access to everything.
And the danger and potential damage live silently in your M365 environment. Without tightening control beyond Microsoft’s defaults, you’re trusting a system that makes it far too easy for users to have more access than they need, and for you to find out only after a breach has already occurred.
Fundamentally, RBAC simplifies access management and supports least-privilege principles, helping to reduce the risk of over-permissioned accounts and privilege-creep – both major causes of data breaches. But what Microsoft 365 offers is not enough.
While failures are rarely linked directly to RBAC alone, we know that the more broad access is, the wider the attack surface. According to CoreView’s 2025 State of M365 Security report, organizations that deploy privileged access management experience 64% fewer security incidents. This makes a lot of sense – the more hands in the pie, the more opportunity for mistakes, malfeasance, or misconfigurations. Misconfigurations make up nearly 99% of all cloud security failures, according to Gartner – restricting privilege can reduce the likelihood of security incidents and privilege escalation attacks.
CoreView’s Chief Revenue Officer, Mark Cravotta talks about the importance of least privilege and limiting risk:
"To protect the organization and individual from the risk that overprivileged access carries, organizations should always apply least privilege for the role and assignment. Danger comes when excess privilege is granted to a role beyond what it requires, opening the door to all kinds of problems – whether unintended or nefarious. Worst case, an attacker could take advantage of a user with excess privilege through, for example, normal phishing techniques, leading to the organization being breached through that single overprivileged user. Once the security defenses are penetrated, all bets are off."
The most critical aspects of not implementing granular least-privilege RBAC relate to the loss of Microsoft 365 tenant resilience and your Zero Trust posture.
Microsoft 365 tenant resilience refers to the idea that one tenant equals one organization. One single issue within a tenant, such as a misconfiguration, has the ability to ripple through the entire organization, causing everything from users being unable to access anything across your M365 environment to a complete shutdown thanks to misconfiguration-driven downtime. Your tenant is a constantly evolving control plane, and as such, security demands locking down access and giving admin accounts to only the required individuals. That is, implementing least-privilege principles to give the minimum possible level of access necessary to perform a role or function.
Yet, despite what most businesses already know about least privilege and Zero Trust, Microsoft reported that 63% of tenants fail to implement least privilege. In addition, our 2025 State of M365 Security survey shows that 89% of IT leaders want to remove admin accounts but can’t, largely due to Microsoft’s complexity. This is a huge risk to tenant resilience and security.
Ignoring RBAC – or underemphasizing the need for greater granularity and tighter controls than Microsoft can offer – also fundamentally undermines Zero Trust by violating its core principles of "never trust, always verify". Without RBAC, organizations are not able to define and enforce access controls, creating security gaps that allow for excessive permissions, uncontrolled lateral movement, and a greater risk of insider threats. And with RBAC that is not fine-grained enough, there remain challenges to security and resilience.
Mark Cravotta expands on the never trust, always verify approach central to Zero Trust:
Zero Trust requires that you verify everyone, and trust no one. Applying overly broad access means your organization has trusted but not proactively verified everyone who has been granted rights beyond what they need, which is fraught with danger.
In addition, failing to implement proper RBAC and least-privilege access opens your organization up to several significant risks:
When roles are too broad, or users accumulate permissions over time, you get “privilege creep” – users end up with access they no longer need. In an article on IAM security nightmares, SecureWorld noted, “The risk: RBAC is great until it isn’t. The problem? Many organisations create broad, over-permissive roles that grant more access than necessary… roles accumulate excessive permissions.”
Organizations do not do this purposely – sometimes, it’s just the nature of how humans work, as Mark Cravotta explains:
"Organizations do their best to try and create roles and related access that are appropriately privileged. They manage those roles, but somewhere along the line, they become busy, which is normal, and may grant access to someone and forget to revoke that access. These are real, everyday challenges that companies may not be equipped to handle today, but there are tools that can help elevate visibility to know what is really going on and automate remediations without human intervention so that some of these natural human foibles, like forgetting to revoke access, do not turn into security nightmares."
Other challenges are less about human error and more about the inability to do more. For example, defining roles too broadly, while it can easily lead to excess privilege and lax access policies, is partly because the tools available do not make it easy, or in some cases, possible to address privilege at a more granular and specific level. Many organizations grant global admin access more widely than they should because Microsoft’s native RBAC model is too complex to do otherwise. This opens the door to compromise – an attacker or bad actor gets access to the entire tenant if they manage to access a single admin account.
One of the biggest threat vectors is the admin account that doesn’t need full tenant rights but has them anyway. That account could be compromised, or the admin could misuse privileges. While no one wants to imagine that insiders in their own company pose a threat, experience says otherwise.
For example, the Coinbase breach in 2025 illustrates this risk. In this attack, hackers paid contractors and employees who had legitimate system access to extract sensitive data. Traditional RBAC models, and the way Microsoft sees them, are insufficient for the kinds of granularity of access and responsibilities required. Better least-privilege management and segmentation of roles would have helped head this off.
Attackers and insiders can exploit overprivileged Microsoft Entra applications, which can then be used to escalate privileges, move laterally, or exfiltrate data. The Midnight Blizzard attack is one example of such an issue. Misconfigured service principals and third-party apps with excessive permissions were exploited to perpetrate privilege escalation.
Lest it seem as though application permissions are not a problem, note this: CoreView’s 2025 State of M365 Security report also found that while global admin usage is down (which is positive news), more than half of surveyed organizations report having 250+ Entra applications with read-write permissions. And it really only takes one such Entra app to make a threat actor as powerful as a global administrator. These apps, which frequently have little to no oversight in terms of managing app permissions, each represent a privileged access point directly into your tenant, vastly expanding the attack surface.
When one account has broad access, a compromise allows the attacker to move laterally in a company’s Microsoft 365 environment. When your Microsoft 365 admin has full tenant rights, a breach of that admin account is a catastrophic event.
And the greater the number of active admin accounts, the larger the attack surface and larger the blast radius. Because the nature of Microsoft 365 is tight interconnectedness of everything, the speed with which security issues propagate is alarming.
And let’s not forget compliance. Poor access controls, including weak RBAC, are active risk vectors and a threat to your compliance posture. Without scoping and controlling access appropriately, you lose visibility of who has access to what. Compliance frameworks, such as major data privacy regulations (GDPR, CCPA, HIPAA, etc.) require enterprises to safeguard data privacy.
By granting broad access permission for data, and not controlling access management carefully, companies not only open themselves up to attack (as happened to global brands like Co-op and Harrods in 2025 when inadequate access management controls played a role in cyberattacks), they risk significant financial and legal penalties as a result of their non-compliance. Granular RBAC can play a role in compliance and the data governance required to remain compliant.
While Microsoft 365 provides built-in roles and delegation models, for large enterprises with distributed administration, multiple business units, geographic segmentation, hybrid or multi-tenant setups, the native capabilities often fall short. In many cases, this forces organizations to grant greater permissions than needed to do a specific job or function.
Some of the key limitations of native RBAC in Microsoft 365 include:
Microsoft has broad built-in admin roles (Global Administrator, User Administrator, Exchange Administrator, etc.), but its own guidance suggests limiting the number of Global Admins and using least-privilege roles. Yet, Microsoft’s native RBAC tools are difficult to set up across large tenants, and some users end up with more power than they need as a result.
Microsoft-native RBAC does not enable fine-grained control over granting privileges, which means that admins may have broad but unintended privileges across the tenant; even a “specialist” admin role might give access beyond a specific business unit, geography or department.
Native M365 permissions fall short of true delegated administration because you cannot customize roles based on your business needs. For example, if you want a regional IT admin to have rights only in their own region, limited to resetting passwords, managing groups, but not license assignment, global user creation, compliance settings, you could struggle with Microsoft-native options alone.
Large enterprises require role lifecycle management (creation, assignment, revocation, review) at scale. Microsoft documentation states access reviews should be used, but many organizations find this complex to do in practice, particularly in multi-tenant or globally distributed scenarios.
In short: Microsoft 365-native RBAC provides a baseline, but for large, complex deployments with strong least-privilege, segmentation, auditing, delegated admin and business-unit-specific needs, native RBAC alone cannot deliver the fine-grained, scalable control needed.
While native RBAC is essential for managing access based on roles in Microsoft 365, it can be augmented using third-party tools, like CoreView, that give organizations the ability to get more granular and context-specific access control that exceeds Microsoft’s standard capabilities.
With virtual tenants, CoreView lets you segment your Microsoft 365 environment by for example, business unit, region or function and then create custom roles with granular permissions, such as for delegated administrators or help desk teams who will only be able to access a subset of users and services relevant to their responsibilities. Instead of granting a support engineer broad Exchange Admin Center access, CoreView lets you create a scoped role that limits visibility and actions to a specific department or geographic group. This reduces risk, enforces the principle of least privilege, and ensures compliance.
CoreView’s RBAC enhancements also enable workflow-based permission assignments and auditable role changes, improving both operational efficiency and accountability. You can automate access provisioning and approval workflows, ensuring that temporary or conditional permissions are granted only when needed and automatically revoked afterward. CoreView also logs every administrative action, providing a clear audit trail that supports security and compliance initiatives such as ISO 27001 or SOC 2.
Ultimately, combining Microsoft 365’s RBAC model with CoreView’s advanced access control capabilities gives organizations fine-grained control over who can do what, where, and when within their tenant.
For CIOs, CISOs, CTOs and security-focused leaders managing Microsoft 365 deployments, the message is clear: Microsoft-native RBAC is not fine-grained enough to meet the security, Zero Trust and tenant resilience imperative. If you fail to implement least-privilege and delegate administration properly and tightly, you expose your environment to both insider risk and external compromise.
CoreView CRO Mark Cravotta adds:
“I like to focus on prevention. When we think about the idea of tenant resilience and the ability to prevent, withstand and recover from cybersecurity incidents, prevention is all about heading off the risks before they become issues and taking steps to reduce the number of vulnerabilities and limit the blast radius in the event of an attack. You can prepare for those things. If you know, for example, that you have taken care of least privilege and someone with limited access rights gets breached, the hacker also has limited rights. You cannot stop every attack – but you can proactively try to limit the damage they can do.”
While Microsoft 365 provides built-in roles and some delegation abilities, native tools lack the granularity, segmentation and scalable governance needed by large enterprises. This is especially true for organizations with multiple business units, geographies, remote helpdesks, contractors or large user-bases.
By defining a robust role model, scoping access properly (via third-party solutions), delegating administration according to business unit, enforcing least-privilege, conducting regular reviews and leveraging tools like CoreView for deeper control, you can significantly reduce your risk surface and support a secure, scalable, and stable Microsoft 365 environment as the building blocks of your Zero Trust posture and tenant resilience.
Check out the Kuppinger Cole “Defend What Matters” report for actionable recommendations on enforcing least privilege and maintaining your Zero Trust posture across your Microsoft 365 environment.
