Modern application architecture is pushing identity into every layer

At a glance

What this is: Cerbos’ panel recap argues that AI, hybrid infrastructure, and microservices are driving identity and authorization concerns deeper into modern application architecture.

Why it matters: It matters because IAM, NHI, and platform teams now have to govern far more machine identities across more environments, with less tolerance for standing privilege and weak traceability.

👉 Read Cerbos’ panel discussion on modern application architecture trends and identity

Context

Modern application architecture is now an identity problem as much as an infrastructure problem. As teams spread workloads across cloud, on-premises, and edge environments, the number of non-human identities they must authenticate, authorise, and govern rises sharply, especially when AI workloads and automation enter the stack.

That shift breaks older assumptions that access is mostly human, mostly static, and mostly tied to one environment. For IAM and NHI programmes, the question is no longer whether workloads need identities, but whether those identities are portable, least-privileged, and lifecycle-managed across the systems that depend on them.

Key questions

Q: How should security teams govern workload identity in hybrid cloud environments?

A: Treat workload identity as a first-class control, not a byproduct of deployment. Give each service a unique identity, remove shared secrets where possible, and use federation so the same workload can authenticate across clouds and on-premises environments. The governance test is whether you can trace, rotate, and revoke access without breaking portability.

Q: Why does microservices architecture increase identity risk for IAM teams?

A: Microservices increase the number of principals, credentials, and service-to-service trust relationships that must be controlled. That creates more opportunities for over-privilege, inconsistent policy, and weak auditability. If the architecture multiplies identities faster than the team can govern them, the security burden rises even when application ownership improves.

Q: What should organisations do to avoid authorization lock-in?

A: Keep authorization decisions outside application logic and express them through stable, standards-based interfaces. That lets policy survive cloud changes, platform swaps, and service refactoring. The practical aim is to make access rules portable enough that a vendor change does not become a rewrite of the security model.

Q: How do teams know if their non-human identity model is too complex?

A: A model is too complex when teams cannot name the owner, lifecycle state, and access purpose of each machine identity without manual digging. If revocation is slow, policy is inconsistent, or service dependencies are opaque, the identity layer has outgrown operational control and needs simplification before it scales further.

Technical breakdown

Workload identity federation across hybrid cloud environments

When applications move across AWS, Google Cloud, and on-premises infrastructure, workload identity has to travel with them. Federation gives a service or workload a cryptographic identity that can be trusted across environments without reusing the same long-lived secret everywhere. SPIFFE and SPIRE are relevant here because they standardise workload identity so services can authenticate without hardcoded credentials or cloud-specific coupling. The architectural value is portability, but the security value is stronger: identity becomes tied to the workload itself rather than the network location or the hosting provider. That matters when AI services burst into different clouds or need to call internal systems from outside their original trust domain. Practical implication: standardise workload identity and federation before expanding hybrid execution paths.

Practical implication: standardise workload identity and federation before expanding hybrid execution paths.

Microservices, monoliths, and the identity blast radius

Microservices do not automatically improve resilience or security. They only reduce coupling when each service owns its data, communicates cleanly, and avoids brittle synchronous dependencies that create cascading failures. A modular monolith can still be the better security choice when it keeps domain boundaries clear without multiplying identities, tokens, and service-to-service trust relationships. From an identity perspective, every new service introduces another principal that needs authentication, policy enforcement, rotation, and auditability. More services can mean more control points, but also more places for over-privilege and inconsistency. Practical implication: evaluate architecture changes through identity blast radius, not deployment style alone.

Practical implication: evaluate architecture changes through identity blast radius, not deployment style alone.

OAuth2, open standards, and authorization portability

The article’s standards argument is fundamentally about reducing lock-in in the identity layer. If applications rely on standard protocols such as HTTP, SQL, and OAuth2, then the business logic can stay independent of a specific cloud or SDK. That same principle applies to authorization. A common authorization API, such as the direction being pushed by the OpenID Foundation AuthZEN work, helps teams keep policy decisions outside application code. The goal is not abstraction for its own sake, but the ability to swap infrastructure components without rewriting access logic. Practical implication: separate policy from code so identity decisions remain portable across platforms.

Practical implication: separate policy from code so identity decisions remain portable across platforms.

NHI Mgmt Group analysis

Identity is becoming the control plane for modern application architecture. The panel’s core message is that cloud mobility, AI workloads, and platform automation all expand the number of non-human principals that must be governed. Once services, pipelines, and AI systems become interchangeable runtime actors, IAM stops being a user problem and becomes an architecture constraint. The practitioner conclusion is straightforward: treat identity design as part of system design, not as a downstream security add-on.

Workload identity federation is now a prerequisite for hybrid architecture, not an optimisation. Portability across cloud and on-prem environments only works when a workload can prove who it is without sharing brittle secrets across every boundary. That is why standards-based identity such as SPIFFE matters in modern estates. The practitioner conclusion is to make federation a default assumption whenever compute can move or burst across environments.

Microservices add identity surface area faster than they add security value. The security outcome depends less on whether a system is a monolith or distributed and more on how many principals, tokens, and trust relationships it forces teams to manage. A modular monolith can reduce identity sprawl while still preserving domain boundaries. The practitioner conclusion is to measure architecture choices by the identities they create and the access they multiply.

Open standards are the only sustainable answer to authorization lock-in. Teams can abstract code, but if the access model is buried inside vendor-specific SDKs, portability disappears as soon as infrastructure changes. Protocol-first design keeps authorization logic movable across clouds and runtimes. The practitioner conclusion is to push policy and identity decisions into explicit layers that survive platform change.

Non-human identity governance is no longer a niche discipline, it is the operating model of cloud-native security. As AI workloads, CI jobs, containers, and service accounts multiply, identity lifecycle management becomes the only practical way to preserve traceability and control. Without unique identities, there is no reliable audit trail or enforceable least privilege. The practitioner conclusion is to govern machine identity with the same seriousness once reserved for human access.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Only 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which shows how quickly the control model is being rewritten.
• For the broader trend line, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how non-human identity governance is evolving across infrastructure and AI.

What this signals

Identity governance is moving from a support function to an architectural constraint. With the number of non-human principals rising across clouds, pipelines, and AI-enabled systems, teams that still treat access as a human-user problem will miss the real control surface. The next programme maturity test is whether identity is designed into runtime architecture, not added after deployment.

The strongest signal for practitioners is that portability and control now have to coexist. If identity, authorization, and lifecycle governance cannot move with the workload, hybrid architecture becomes a source of unmanaged privilege rather than resilience. That is why platform teams and IAM teams need a shared operating model, not separate reviews.

For teams building toward agentic AI, the relevant benchmark is whether machine identity can be explained, audited, and revoked without manual archaeology. That is the difference between distributed systems that scale safely and distributed systems that simply spread risk further.

For practitioners

• Inventory every non-human principal by execution context Map service accounts, API keys, CI jobs, containers, and AI workloads to the environments where they run, then assign an owner and lifecycle state to each identity. This makes hidden trust chains visible and gives IAM teams a realistic scope for review and revocation.
• Adopt workload federation before expanding multi-cloud execution Use standards-based workload identity so services can authenticate across clouds and on-premises without copied secrets or provider-specific credentials. Link the approach to platform engineering so identity decisions are part of deployment design, not an afterthought.
• Separate authorization logic from application code Move policy decisions into a dedicated layer and keep application services consuming those decisions through stable interfaces. That reduces lock-in, makes policy changes auditable, and lets teams switch infrastructure components without rewriting access control logic.
• Use architecture reviews to cap identity blast radius Before splitting a system into more services, estimate how many new identities, trust relationships, and policy exceptions the change will create. If the move increases complexity without a clear control gain, keep the simpler architecture and improve boundaries first.

Key takeaways

• Modern application architecture is no longer just a deployment pattern, it is an identity governance problem.
• Hybrid cloud, AI workloads, and microservices all increase the number of non-human identities that must be controlled.
• Teams that want portability need standards-based workload identity, externalised authorization, and clear lifecycle ownership.

Key terms

• Workload Identity: A workload identity is the cryptographic identity a service, container, or automated process uses to authenticate itself. It replaces shared secrets and static credentials with a uniquely attributable principal that can be authorised, audited, and revoked like any other identity in the environment.
• Identity Blast Radius: Identity blast radius is the amount of access, trust, and downstream dependency exposed when one identity is misused or compromised. In distributed systems, the blast radius grows with every added service account, token, and policy exception, so architectural choices directly affect containment.
• Authorization Portability: Authorization portability is the ability to move access decisions across applications, clouds, or runtimes without rewriting business logic. It depends on standards-based policy interfaces and modular design, so identity controls remain stable even when infrastructure providers or deployment models change.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: Building the future of modern application architecture. Read the original.