Transforming our approach to sensitivity labels at Microsoft with Microsoft Entra

Security groups serve as the backbone of our approach to access control across the Microsoft corporate tenant. These groups determine who has access to different resources across our network, including Azure subscriptions, Power BI reports, SharePoint sites, and more.

For years, our security groups operated without consistent, policy‑based guardrails. As a result, we couldn’t uniformly control guest access to sensitive resources or apply governance consistently across different group types.

Addressing this required a complex, coordinated effort by our team here in Microsoft Digital, the company’s IT organization, and the Microsoft Entra product team.

“Because IT security is our highest priority at Microsoft, we knew we needed a better approach to limiting access to groups within our tenant. And we realized that Microsoft Entra was a powerful in-house solution that represented our best path forward to solve for this challenge.”

David Johnson, principal product manager architect, Microsoft Digital

The result is a new approach to sensitivity labels across the organization that strengthens our security posture, which benefits Microsoft and our customers.

“Because IT security is our highest priority at Microsoft, we knew we needed a better approach to limiting access to groups within our tenant,” says David Johnson, a principal product manager architect in Microsoft Digital. “And we realized that Microsoft Entra was a powerful in-house solution that represented our best path forward to solve for this challenge.”

Closing the security gap

Sensitivity labels for Microsoft 365 groups are labels that govern join and access restrictions for membership and sharing. They have been a product feature since 2020. But sensitivity labels for security groups—labels that enforce rules about who can join a group—had no equivalent.

This meant that organizations that wanted to govern who could join a security group or determine if guests are permitted and how group membership is managed had to either lock down the group creation process entirely, or rely on reactive scanning after the fact.

“Security groups are a key piece of our efforts to secure sensitive resources,” says Mohit Bhargava, a principal product manager on the Microsoft Entra team, which manages the Entra family of identity and network access products. “We wanted to apply policies to protect who could be in security groups so that the sensitive resources in those groups would remain secure.”

“Whoever gets into an Azure security group can have access to all the resources associated with the Azure subscription. That’s a potential high-severity threat.”

Basanth Kakumani, software engineer II, Microsoft Digital

The security risk is real. If an unauthorized guest account ends up as a member of a security group that governs access to an Azure subscription, that guest gains access to every resource inside that subscription.

“Whoever gets into an Azure security group can have access to all the resources associated with the Azure subscription,” says Basanth Kakumani, a software engineer II in Microsoft Digital. “That’s a potential high-severity threat.”

Another priority was the need for consistency across experiences.

“Microsoft 365 groups have supported labeling for a very long time,” Bhargava says. “Customers have an expectation that there’s parity across group types, so that they can govern them uniformly. That was another driving factor for this work.”

Security groups reuse the same sensitivity labels already configured for Microsoft 365 groups and SharePoint sites in Microsoft Purview—so admins don’t need to create or manage a separate set of labels. This reuse reduces configuration overhead and supports a more consistent governance model across group types.

Security workarounds, and why they fell short

Without sensitivity label support, we had to make do with alternative solutions. The most common one was simply preventing certain users from creating any security groups at all.

In the Microsoft tenant, this meant that employees who needed a security group had to fill out a form that had custom business logic behind it.

“We had on-premises, Active Directory, synchronization, tooling, and customization,” Johnson says. “This caused latency, from the time you created your group to the time it would show cloud membership. If you wanted to manage your membership, you had to do it on premises, AD, and then wait for it to sync to Entra.”

Neither centralized control nor reactive governance was a satisfying solution to prevent policy violations.

“This is really about making reactive things more proactive. We want to catch problems before they occur.”

John Begley, principal software engineer, Microsoft Digital

Typically, IT is going to manage this in one of two ways: Either we turn off self-service and manage everything on behalf of users, or we do reactive governance, which includes scanning groups and looking for policy violations.

Those aren’t super effective at preempting violations.

“This is really about making reactive things more proactive,” says John Begley, a principal software engineer in Microsoft Digital. “We want to catch problems before they occur.”

A collaborative solution

Coming up with a solution to this challenge required a genuine partnership.

We at Microsoft Digital approached the Entra product team and explained the problem we were trying to solve. Rather than simply handling this as a feature request, the two teams agreed to a co-development arrangement.

“Having access to a very large customer who cares deeply about security was extremely helpful. If it works for Microsoft, which is so complicated and huge, it’s going to work for smaller-sized tenants too.”

Mohit Bhargava, principal product manager, Microsoft Entra

Microsoft Digital team members would work alongside Entra engineers as the feature was built, serving simultaneously as implementation partner, design critic, and test environment—what we like to call our Customer Zero role.

Bhargava found the partnership equally illuminating from the product side.

“Having access to a very large customer who cares deeply about security was extremely helpful,” he says. “If it works for Microsoft, which is so complicated and huge, it’s going to work for smaller-sized tenants too.”

For Begley and his team, working closely with the product team revealed how complex the solution actually was.

“Both the product team and Microsoft Digital walked into this thinking a fix was going to be simpler than what it turned out to be,” Begley says. “It’s been eye-opening to see how the product is built, how it runs, what all the moving parts are. We learned early on that there was significant co‑development happening within Entra itself, across teams with very different areas of expertise.”

That dynamic played out in specific feature decisions. The team’s original plan did not include support for agent access controls and didn’t include the ability to prevent AI agents from joining sensitive security groups. This is something the product group quickly addressed and resolved after our team in Microsoft Digital raised it as a concern.

“One of the first customers who raised it was Microsoft Digital,” Bhargava says. “They said we needed need to start thinking about it ahead of time to get ahead of the problem.”

Sensitivity labels for Microsoft Entra cloud security groups are now in public preview. The same labels you publish in Microsoft Purview for Microsoft 365 groups and sites now apply to Entra security groups. Visit Microsoft Learn for scope, supported scenarios, and current preview behaviors.

Changes afoot for IT admins and employees

The practical impact of this solution lands on both sides of the relationship between Microsoft Digital and the company’s employees.

“Now I can’t accidentally have guests in an internal-only group, which changes the dynamic. Employees can create their own Entra security groups now, without us having to worry that they’ll be inviting guests where they shouldn’t be.”

David Johnson, principal product manager architect, Microsoft Digital

For IT admins, the shift is from reactive remediation to proactive prevention. For employees, it means self-service action with security groups become viable again, without the security risks that made organizations reluctant to enable it before.

“Now I can’t accidentally have guests in an internal-only group, which changes the dynamic,” Johnson says. “Employees can create their own Entra security groups now, without us having to worry that they’ll be inviting guests where they shouldn’t be.”

Johnson underscores the broader ambition behind the shift, which is to allow employees to create and manage groups directly in Entra.

“A company that can unblock self-service action by its employees with confidence, knowing that there’s an additional level of protection—that’s very important,” he says.

Looking ahead: AI and the expanding policy surface

Labeling support for security groups is already being extended across the organization, with AI governance in mind.

Adding the ability to block agents from joining sensitive security groups is our next logical step. Guest membership is enforced via allow-to-add guest policy, but agents won’t join in the same way. Rather, we will set policies in Purview and then use labels to control if an agent can join a group.

The longer-term vision involves extending oversharing prevention beyond Entra itself. This will make it impossible (not just detectable) to accidentally assign a highly confidential resource to an unlabeled or inappropriately scoped security group. The foundation we’ve built with labeling in Entra is what makes this vital step possible.

“We want to get into the preventative aspect,” Johnson says. “The goal is to make it so it’s not possible to overshare in the first place.”