Microsoft Entra ID (formerly Azure Active Directory) is a cloud-based identity and access management solution that has become a go-to choice for businesses looking to simplify how they handle authentication. Its main appeal is single sign-on. Instead of managing separate login systems across multiple on-premises or cloud applications, organizations get one centralized point of control.
From a security standpoint alone, that is a significant advantage: administrators can monitor all sign-in attempts from a single dashboard, enforce consistent authentication policies, and reduce the overhead of maintaining multiple credential stores. On top of that, it comes backed by Microsoft, one of the most trusted names in enterprise technology, which makes adoption an easier sell.
Microsoft Entra does not just promise convenience though; it also promises security. It markets itself as a platform that prevents identity attacks, enforces least privilege, and unifies access control. This report examines where those promises fall short, specifically when Entra is used as an identity provider for cloud platform federation via SAML.
The problem is that while Entra handles authentication well, it is not truly in control of what happens on the other side of that federation. Cloud platforms like AWS and GCP have their own deeply independent IAM systems with their own authorization logic, their own constantly evolving interfaces, and their own proprietary mechanisms that Entra has no real authority over. More critically, Entra ends up functioning purely as an authentication layer; it verifies who you are, but it does not govern what you can do. Throughout this paper, references are made from NIST SP 800-53 Rev 5 to serve as the evaluative framework for assessing the security vulnerabilities identified.
This report will begin with security vulnerability within Entra itself before branching out into the endpoints. Some of the most significant vulnerabilities exist within Entra itself, before a single federated request is ever made. The User Administrator role is one of the clearest examples of this.
User Administrator is a built-in Entra role positioned well below Global Administrator in terms of stated scope. Microsoft defines it as a role for managing users and groups, handling password resets, monitoring service health, and assigning licenses. It is commonly delegated to help desk staff, HR systems, or IT operations personnel who need to manage the user lifecycle without holding full tenant control. On the surface, this looks like responsible least privilege design. The problem is that "managing groups" and "assigning licenses" are not as narrowly scoped as they appear.
In Entra, enterprise application access is controlled through group membership. When an organization configures AWS Single Sign on Account Access, it creates a group — say, GRP-PROD-DEVOPS-AWS — and maps that group to an AWS IAM role. Any user who is a member of that group, when they authenticate through the SAML-federated enterprise app, receives a token asserting that role. Entra does not perform any additional access review at the moment of sign-in. If you are in the group, you get the role.
A User Administrator can modify group memberships. Which means a User Administrator can add themselves — or any other user — to GRP-PROD-DEVOPS-AWS, authenticate to the enterprise application, and arrive in AWS with whatever permissions that role carries. If that role is ROLE-PROD-DEVOPS-FULL with AdministratorAccess, the User Administrator just escalated themselves to full AWS administrative access through nothing more than a group membership change.
No approval was required. No second reviewer was notified. Nothing in the default Entra workflow flagged this as an access escalation rather than a routine group management task. The audit log will show a group membership change, which looks identical to onboarding a new employee.
This scenario is a textbook violation of AC-5. AC-5 requires that organizations divide significant responsibilities among multiple individuals so that no single person can complete a sensitive action unilaterally. A User Administrator who can modify the group memberships that control application access holds both sides of that transaction simultaneously; there is no structural separation, only the assumption that the administrator will not misuse the capability.
AC-6 is equally implicated. The User Administrator role grants capabilities beyond what the job function requires. An operator responsible for onboarding employees and resetting passwords does not need the ability to modify the membership of groups that control access to production cloud infrastructure. The role conflates identity lifecycle management with access assignment, and that conflation is the vulnerability.
If the User Administrator is routinely assigned to help desk personnel without any accompanying restrictions on which groups they can manage, that becomes the de facto baseline configuration — one that carries a privilege escalation path as a default feature. When the insecure configuration is the baseline, there is nothing to trigger a review.
Microsoft does not treat this as an undocumented bug. Administrative units can be used to scope a User Administrator's reach to a specific subset of users and groups. Entitlement Management and access packages can add approval workflows to group membership changes for sensitive applications. These are real mitigations.
The problem is that none of them are configured by default. A freshly assigned User Administrator in a standard Entra tenant has unrestricted group management scope across the directory. Most environments — particularly those without dedicated identity engineering resources — never implement them. The platform offers the tools to build a secure configuration, but the default posture requires active hardening to reach that standard.
SAML federation is how Entra's promise extends beyond Microsoft's own ecosystem into platforms like AWS. In practice, federating into AWS means Entra is now bridging into one of the most expansive and frequently evolving IAM systems in cloud computing. The places where it struggles to keep up are exactly where security vulnerabilities emerge.
AWS Single-Account Access is the older of the two approaches. It federates Entra directly into a single AWS account by establishing a SAML trust relationship between Entra and AWS IAM. Role assignments are handled manually. This method works, but it does not scale cleanly. AWS itself steers new implementations away from this model, recommending Identity Center for any modern deployment.
AWS IAM Identity Center is the current recommended approach and functions more like a native integration. Rather than mapping roles one by one, Identity Center uses SCIM provisioning to sync users and groups directly from Entra, and permission sets to define access in a more structured and auditable way.
Connecting an Entra ID tenant to an AWS Single Account requires creating multiple interdependent objects across two platforms. Because every one of these objects maps to the others, their names form a chain. A weak link anywhere in that chain breaks the traceability of the entire access path.
| Layer | ✓ Good Name | ✗ Poor Name |
|---|---|---|
| Entra ID — Group | AWS-Billing-Readers | Accountants |
| Entra — Enterprise App | AWS-Billing-Read | AWS SSO |
| AWS — Identity Provider | EntraID-Production | SAML_Provider_1 |
| AWS IAM — Role | Billing-ReadOnly-EntraID | FinanceRole |
| AWS IAM — Policy | Billing-ReadOnly-Policy | FinancePolicy |
Step 1 — Group Creation in Entra ID. The first step was creating a Security group in Entra. Two groups existed in the lab: AWS-Billing-Readers and Aws Finance Group. The difference is immediately obvious. AWS-Billing-Readers tells you the platform, the resource, and the permission level at a glance. Aws Finance Group tells you nothing about access. An auditor reviewing this group cannot determine what it grants access to without clicking into it manually.
Step 2 — Enterprise Application Assignment. The application list showed four entries including AWS-Billing-Read and Google Lab Federation side by side. As the number of applications grows, an unstructured name like Google Lab Federation becomes impossible to assess at a glance — no environment, no permission level, no platform context.
Step 3 — IAM Role Alignment in AWS. On the AWS side, searching for billing roles returned three results: AWSReservedSSO_Billing_c49456ed96e90a77, Billing-Cost-Management, and Billing-ReadOnly-EntraID. Only the last one clearly communicates its permission level and identity provider. The auto-generated UUID in the first is unreadable. The second is ambiguous — cost management could mean read-only reporting or write access to billing configuration.
The lab confirmed that naming inconsistency directly breaks the access chain between Entra and AWS. When the link between a group in Entra and a role in AWS cannot be traced by name alone, access reviews get skipped, over-permissioning goes undetected, and incident response slows down — exactly what NIST SP 800-53 AC-2, AC-6, and CM-2 are designed to prevent.
Configuring AWS Single-Account Access through Entra requires the creation of an IAM user within the account. This user serves as the programmatic bridge between Entra and AWS, and its creation introduces a credential surface that exists entirely outside of Entra's control.
When this IAM user is created, AWS presents two access options. The first is programmatic access only, using access keys for API and CLI interactions. The second is console access — the same account is given a password, allowing it to log directly into the AWS Management Console without going through the SAML federation flow at all.
The moment console access is enabled on that IAM user, you have introduced a parallel authentication path that completely bypasses Entra. None of Entra's Conditional Access policies apply. MFA requirements configured in Entra do not apply. Sign-in risk detection does not apply. The entire security layer Entra provides is simply not in the picture.
The federation architecture that was supposed to centralize authentication has a side door left open by the configuration that enables it.
The threat posed by exposed IAM credentials is not theoretical. The following three incidents demonstrate what happens when AWS credential surfaces are left unmanaged.
All three incidents share the same underlying pattern. IAM credentials existed as standalone objects outside any federated identity flow. No MFA was attached to them. No identity provider was watching them. When those credentials were obtained, the attacker walked straight into AWS with no challenge.
This maps to several NIST SP 800-53 controls simultaneously. IA-2 requires unique identification and authentication — a shared IAM credential violates this. IA-5 requires managed authenticators with rotation policies — IAM credentials are set once and rarely rotated. AC-17 requires remote access be monitored and controlled — console access through a standing IAM credential produces CloudTrail logs not correlated with Entra's sign-in logs. AC-2 requires accounts be managed through their lifecycle — the IAM user often outlives its original purpose and is never formally reviewed.
The straightforward mitigation is to restrict the IAM user to programmatic access only and disable console access entirely. If console fallback access is genuinely needed, it should be a separate, tightly scoped account with MFA enforced at the AWS level, access logging routed to a monitored destination, and a formal review cycle attached to it. It should not be the same account used for the SAML integration.
The vulnerabilities examined in this paper are not primarily the result of technical flaws in Entra or AWS individually. They are the result of an architectural gap between two systems that each handle part of the access control problem but neither owns it completely.
[ORG]-[ENV]-[TEAM]-[RESOURCE-TYPE]-[PERMISSION-LEVEL]. A consistent naming convention is the foundation on which AC-2 account reviews, AC-6 least privilege audits, and CM-2 baseline configuration documentation all depend.The vulnerabilities identified in the Microsoft Entra ID to AWS federation are not isolated to a single cloud platform. They also apply in GCP but in their own way. GCP requires the users to have a unique domain — users like elvisboansi@gmail.com cannot be used to federate. It requires a unique domain name. Secondly it ties such users into its Google ecosystem once the user is established into its federated system, introducing a distinct set of risks unique to how Google has built its cloud identity architecture.
GCP's Workforce Identity Federation requires domain verification before federated users can access the environment. On the surface this appears to strengthen security. In practice, the verification happens at the GCP organization level, while Entra still controls who receives a token under that domain. Any account that exists in Entra under the verified domain is automatically a valid GCP identity once federation is configured, and GCP has no independent mechanism to challenge or review that trust.
The consequence is that a stale, over-permissioned, or compromised Entra account translates directly into a valid GCP identity. Disabling a user in Entra does not automatically revoke their GCP access because GCP is not notified of that change. The domain boundary creates a false impression of control.
Both controls require that identity lifecycle events including deprovisioning be managed end to end and not just at the authentication layer. GCP Workforce Identity Federation does not support SCIM provisioning from Entra. There is no lifecycle hook between the two platforms. When a user is offboarded in Entra, their GCP session remains valid until the token naturally expires.
AWS federated access via SAML keeps the enterprise and consumer identity surfaces cleanly separated. A federated AWS user authenticates through Entra and receives a scoped session. There is no underlying AWS account password for that user and no consumer AWS pathway available.
GCP's architecture does not maintain this separation. Because federation requires a Google identity tied to the verified domain, a Google account credential exists alongside the SAML federation path and can be used to authenticate directly to Google without going through Entra at all. None of Entra's Conditional Access policies apply. MFA requirements configured in Entra do not apply. Furthermore, Google account recovery paths — phone-based recovery, backup email — become viable attack vectors completely invisible to the organization's identity platform.
This is structurally identical to the console access trap identified in the AWS section but with an important distinction. In AWS, the parallel path requires the deliberate creation of an IAM user with console access enabled; it is a configuration choice the administrator makes and can therefore be prevented. In GCP, the parallel path is a consequence of how Google's identity architecture works. It is not a configuration mistake; it is a property of the platform itself.
When a federated user authenticates into GCP through Entra and lands in the GCP Console, Google presents the full GCP product catalog. Every service, every menu, and every feature is visible and accessible regardless of what IAM permissions that user actually holds. This is fundamentally different from AWS, where the console interface is scoped to what the user's IAM role permits. In GCP, a user granted access to a single Cloud Storage bucket sees the same console as an organization administrator.
When a federated enterprise user clicks a service they do not have IAM permissions for, GCP's response is not an access denied message. Instead it initiates a consumer account onboarding flow, treating the enterprise user as a potential new Google customer. A federated employee could inadvertently create a personal GCP project linked to their corporate Google identity. Any resources created in that personal project exist entirely outside the organization's control plane and will not be caught by the organization's offboarding process.
The vulnerabilities identified across both platforms share the same root cause. Entra authenticates but does not authorize. However, they manifest differently in each environment.
| Category | AWS (Single-Account Access) | GCP (Workforce Identity Federation) |
|---|---|---|
| Parallel auth path | IAM user with console access enabled | Google account credential tied to domain |
| Parallel path origin | Configuration choice by administrator | Built into GCP platform architecture |
| Deprovisioning gap | Partial; AWS IAM Identity Center supports SCIM | Full; no SCIM provisioning from Entra |
| Ecosystem blast radius | Contained to the AWS account | Extends across all Google Workspace services |
| Console scoping | Interface scoped to IAM role permissions | Full GCP product catalog shown to all users |
| Consumer account risk | Not present | Federated users can create personal GCP projects |
| Conditional Access reach | Ends at SAML assertion issuance | Ends at SAML assertion issuance |
| Account recovery attack surface | Not applicable | Google account recovery paths are viable vectors |
GCP introduces additional risks through its lack of SCIM deprovisioning, its broader ecosystem entanglement, its consumer account bleed behavior, and the fact that its parallel authentication path is architectural rather than configurable. These differences confirm that the problem is not specific to AWS or to any particular implementation choice. It is a structural property of how federated identity works across independent cloud platforms.