Every cloud environment needs to answer a foundational question: where do user identities live? The two primary approaches are direct IAM users — accounts created and managed natively within the cloud provider — and federated identity, where a central identity provider (IdP) authenticates users and passes assertions to the cloud platform via protocols like SAML 2.0 or OpenID Connect (OIDC). This architectural choice has far-reaching implications for security, operational efficiency, and the organization's ability to enforce consistent access policies across a multi-cloud or hybrid environment.
Most enterprise security guidance strongly favors federation, and for good reason. However, direct IAM users are not inherently insecure, and there are legitimate scenarios where they remain the appropriate choice. The goal is to make a deliberate, informed architectural decision rather than defaulting into a hybrid state where some users are federated, some are direct, and no one has a clear picture of the overall identity landscape.
The Case for Federated Identity and Single Sign-On
Federation centralizes identity management in a single authoritative source — typically an identity provider like Okta, Microsoft Entra ID (formerly Azure AD), Ping Identity, or Google Workspace. When a user is hired, their identity is provisioned in the IdP and they automatically gain access to all connected cloud environments based on their group memberships and role assignments. When they leave the organization, disabling their IdP account immediately revokes access everywhere. This single point of lifecycle management is the most compelling security benefit of federation.
Beyond lifecycle management, federation enables consistent security controls across all cloud environments. MFA policies, conditional access rules, session duration limits, and device trust requirements are configured once in the IdP and enforced universally. Without federation, each cloud account requires its own MFA configuration, its own password policy, and its own session management — creating inconsistencies and gaps that attackers can exploit. For organizations operating across AWS, Azure, and GCP, federation through a single IdP is the only practical way to maintain uniform identity security.
Federation also generates a centralized authentication audit trail. Every login, MFA challenge, and session creation is logged in the IdP, providing a single source of truth for who accessed what and when. This centralized logging simplifies incident investigation and compliance reporting compared to correlating authentication events across multiple cloud provider consoles.
SAML 2.0 vs. OpenID Connect: Protocol Considerations
The two dominant federation protocols are SAML 2.0 and OpenID Connect (OIDC), and the choice between them affects architecture, token handling, and operational characteristics. SAML 2.0 is the older protocol, designed for browser-based SSO flows. It uses XML-based assertions and has deep support across enterprise identity providers and cloud platforms. AWS IAM Identity Center, Azure AD, and GCP Workforce Identity Federation all support SAML 2.0 natively. SAML is well-understood, well-tested, and sufficient for the majority of enterprise federation use cases.
OIDC is the newer protocol, built on OAuth 2.0, and uses JSON-based tokens (JWTs) that are smaller and easier to work with than SAML assertions. OIDC is increasingly preferred for modern applications, API-based authentication, and workload identity federation. GCP Workload Identity Federation, AWS IAM OIDC providers for service accounts, and Azure Workload Identity all use OIDC to allow workloads to authenticate without long-lived credentials. For organizations building cloud-native applications or implementing workload identity federation, OIDC is typically the better choice.
In practice, many organizations use both protocols: SAML for human user SSO into cloud consoles and OIDC for workload identity and modern application authentication. The important principle is to select protocols deliberately based on the authentication flow requirements rather than defaulting to whichever protocol the first integration happened to use. Ensure your IdP supports both protocols robustly, as most enterprise-grade providers do.
When Direct IAM Users Are Acceptable
Despite the advantages of federation, direct IAM users remain appropriate in specific scenarios. The most common is break-glass access — a small number of emergency accounts that can access cloud environments when the IdP is unavailable. These accounts should be protected with hardware MFA tokens, their credentials stored in a physical safe or secrets vault, and their usage monitored with high-severity alerts. Without break-glass accounts, an IdP outage could lock an organization out of its own cloud infrastructure during a critical incident.
Direct IAM users may also be appropriate for small organizations or early-stage startups with a single cloud account and fewer than ten users. For these teams, the operational overhead of configuring and maintaining an IdP federation may exceed the security benefits, particularly if the team is disciplined about MFA and credential management. However, this calculus changes quickly as the organization grows. Migrating from direct users to federation becomes increasingly difficult as the number of users and cloud accounts increases, so organizations should plan for federation early even if they do not implement it immediately.
Automated service accounts that require static credentials for legacy integrations may also exist as direct IAM users when federation is not supported by the consuming system. In these cases, apply compensating controls: rotate credentials on a short schedule, restrict the source IP ranges that can use the credentials, and monitor for usage anomalies. These accounts should be documented as technical debt with a migration path toward federated workload identity.
Planning a Migration from Direct Users to Federation
Migrating from direct IAM users to federated identity requires careful planning to avoid disrupting user access. Begin by selecting and configuring your identity provider. Evaluate options based on your existing directory infrastructure (Active Directory environments naturally align with Entra ID, while cloud-native organizations may prefer Okta or Google Workspace), your multi-cloud requirements (ensure the IdP supports federation with every cloud provider you use), and your budget for licensing and support.
Establish the federation trust between your IdP and each cloud account, configure group-to-role mappings, and validate that federated users receive the correct permissions. Run a parallel period where both direct IAM users and federated access work simultaneously, allowing users to verify their federated access before their direct accounts are disabled. This parallel period typically lasts two to four weeks and should include testing of all critical workflows — console access, CLI access via temporary credentials, and programmatic access via SDKs.
After the parallel period, disable direct user accounts (do not delete them immediately — retain them in a disabled state for 30 to 60 days in case rollback is needed). Update all documentation, runbooks, and onboarding procedures to reference the federated access path. Finally, establish break-glass accounts as described above, and configure alerting for any authentication event on these emergency accounts. The migration is complete when all routine human access flows through the IdP and direct accounts exist only for documented emergency purposes.