Why your identity architecture needs a cloud-native rethink
8 minute read
Most organizations have outgrown their identity infrastructure. The Identity Provider (IdP) configurations and directory services that worked five years ago were not designed for distributed workforces, hundreds of cloud applications, and machine identities that outnumber people. Here, we cover the principles of designing an identity architecture that keeps up.
Explore Duo's approach to identity
Key takeaways
Legacy identity infrastructure creates security blind spots and operational drag that compound as organizations grow.
Cloud-native IAM is not just cloud-hosted identity. It is an identity built for API-driven, distributed, continuously verified environments.
Identity orchestration platforms coordinate authentication across multiple identity sources, devices, and risk signals to make dynamic access decisions.
An identity management roadmap starts with consolidation and ends with continuous verification. Most organizations are somewhere in between.
Why can’t I just update my legacy identity infrastructure?
Most identity infrastructure was designed for a specific moment: everyone works in the same building, every application runs on the same network, and the IT team provisions accounts by hand. That moment has passed.
The directory services and IdP configurations many organizations still rely on were built for on-premises environments with a fixed number of users and applications. They work well in that context. But when the workforce goes remote, applications move to the cloud, and contractors need access alongside employees, these systems face pressure they were not designed to handle.
Remote or distributed environments add complexity. Provisioning a new employee can take days instead of minutes when accounts have to be created manually across dozens of applications. Offboarding is worse. A forgotten account in a decommissioned system can become an unmonitored entry point—still active, still holding permissions, but no longer on anyone's radar. Password reset tickets consume help desk capacity that could go elsewhere. And every disconnected identity tool adds a gap that security teams have to monitor separately.
None of this makes legacy systems bad. They are simply a mismatch for this environment. That gap is where most identity management transformation efforts begin.
What is cloud-native IAM, really?
Cloud-native IAM is not the same thing as cloud-hosted identity. Hosting an on-premises directory in someone else's data center does not make it cloud-native. In that case, the infrastructure may change location, but the architecture remains the same.
Cloud-native IAM means the system was designed from the start for how modern organizations work: API-driven, elastically scalable, protocol-flexible. These are built to handle distributed users, devices, and applications without requiring the IT team to manage the underlying infrastructure.
At the center of any cloud-native IAM strategy is the identity provider, the system responsible for authenticating users and passing verified identity to applications. The IdP is the foundation. Our complete guide to identity providers explains how IdPs work, what to look for, and how to evaluate your options. Cloud-native IAM extends that foundation with capabilities like adaptive authentication, device trust, automated provisioning, and centralized policy enforcement across every connected application.
For organizations managing SaaS identity and access management across dozens of applications, this distinction matters. A cloud-hosted IdP may still require manual configuration for each new application. A cloud-native identity platform handles that integration through standard protocols and automated provisioning, which can reduce the time from days to minutes.
How can I future-proof my identity architecture?
Modern identity architecture design starts with a principle: separate authentication from the applications that depend on it. When applications manage their own credentials, every application becomes a potential point of compromise because each one stores and verifies passwords independently. When a centralized IdP handles authentication and passes signed assertions to applications, credentials live in one place and security policy applies consistently.
That separation is the foundation. The architecture built on top of it determines whether the organization can adapt as requirements change.
Your first decision: the identity provider
The IdP is the first decision in any identity architecture because it defines so many others downstream. Protocol support determines which applications can connect. MFA enforcement determines how well the authentication layer resists phishing. Directory integration determines whether existing employee records can carry over or need to be rebuilt. Automated provisioning, device trust, and adaptive access all build on what the IdP provides.
An IdP that supports SAML for legacy enterprise applications, OIDC for modern cloud tools, and SCIM for automated account provisioning gives the organization protocol flexibility without requiring application-by-application configuration. That flexibility becomes critical as the number of connected applications grows.
Bridge gaps with orchestration
A single IdP works well when the organization has one identity source and one set of access policies. Most organizations have outgrown that model. Common issues include:
A company acquires another company that runs a different IdP.
Contractors arrive with their own identity credentials.
Customer-facing applications require a separate authentication flow from internal tools.
This is where an identity orchestration platform fits in. Rather than replacing what already works, orchestration coordinates authentication across multiple identity sources. It routes each access request to the right provider based on who the user is, what they are trying to reach, and what risk signals are present. Device posture, location, login behavior, and time of day all factor into the decision.
The result is not a bigger IdP. It is an identity layer that sits above the IdPs and makes dynamic access decisions across all of them. Identity-related incidents affected 90% of large organizations in 2024, with 84% reporting a direct business impact (IDSA, 2024). Consistent policy enforcement and centralized credential management shrinks the gaps between disconnected tools. And during acquisitions, teams can authenticate through their existing IdP from day one instead of waiting for a full migration.
Ready to build an identity management roadmap?
Identity management transformation does not happen in a single project. It happens in phases. Each phase delivers immediate value while setting up the next. Here is a practical sequence that works regardless of where the organization starts.
Consolidate identity providers. Audit how many IdPs, directories, and authentication tools the organization uses today. Identify redundancies. The goal is not to collapse everything into one system overnight. It is to map what exists so the organization can make informed decisions about what to keep, what to merge, and what to retire.
Enable cloud-native SSO and MFA. Connect applications to the consolidated IdP using standard protocols. Enforce MFA at the IdP layer so every connected application inherits the same authentication standard. Prioritize phishing-resistant methods like passkeys and biometrics over SMS codes.
Add device trust and risk signals. Authentication answers who someone is. Device trust answers whether the device they are using is secure and up to date. Combining both gives the IdP the context it needs to make better access decisions. A known user on a compromised device is still a risk.
Move toward continuous verification and orchestration. Replace point-in-time authentication with continuous assessment. Layer in orchestration to coordinate across multiple identity sources. This is the phase where the identity architecture becomes adaptive, making real-time decisions based on behavior, risk, and context rather than static rules.
What holds organizations back?
If the roadmap is straightforward, why do so many organizations stall at phase one?
Legacy application dependencies limit your options
Some applications were built to authenticate against a specific directory and cannot easily point elsewhere. These applications anchor the organization to its current identity infrastructure regardless of what the rest of the environment needs. The workaround is federation or protocol bridging, not a full migration.
Organizational inertia slows buy-in
Identity infrastructure touches every user and every application. Teams that have managed the same directory for a decade may resist a transition, not because the current system works well, but because the cost or perceived risk of getting the transition wrong feels higher than the cost of staying put.
Budget constraints prioritize other projects
Identity projects compete with every other security and IT priority. The business case is clearest when the organization can quantify the cost of the current state: hours spent on manual provisioning, tickets generated by password resets, incidents traced to identity gaps. Without those numbers, identity modernization stays in the backlog.
Skills gaps leave teams uncertain
Cloud-native IAM requires different expertise than managing an on-premises directory. Protocols like OIDC, concepts like device trust, and tools like SCIM-based provisioning are not part of every IT team's current skill set. Training and hiring are part of the roadmap, not a prerequisite.
None of these blockers are permanent or insurmountable. And they respond to the same approach: start with the audit, quantify the cost of the current state, and build the business case one phase at a time.
Every organization's identity architecture looks different, and so does the path forward
Whether you are consolidating identity providers, evaluating cloud-native IAM platforms, or planning your first step toward orchestration, a conversation with someone who has seen the full range of environments can save months of trial and error.
Talk to a Cisco Duo identity security expert to map your current state and identify where to start.