By NHI Mgmt Group Editorial TeamPublished 2026-06-09Domain: Governance & RiskSource: Soffid

TL;DR: Choosing between on-premises and cloud IAM is not a theory exercise, because compliance, legacy integrations, cost, security investment, and NHI sprawl all shift the risk profile, according to Soffid and Verizon. The decisive question is whether your identity model can sustain centralized control as cloud scale, third-party dependencies, and non-human identities increase.


At a glance

What this is: This is an analysis of how on-premises and cloud IAM architectures change the security and governance burden, with NHI sprawl and legacy integration risk as the main pressure points.

Why it matters: It matters because IAM teams have to choose an operating model that can hold up under compliance demands, hybrid complexity, and non-human identity growth without losing control.

By the numbers:

👉 Read Soffid's analysis of on-premises vs cloud IAM architecture choices


Context

On-premises vs cloud IAM is really a governance choice about where control, operating responsibility, and change risk sit. The article frames that choice around compliance, legacy integration stability, cost, security assurance, and the growth of non-human identities, which makes it directly relevant to identity architecture planning rather than infrastructure preference.

For IAM leaders, the harder issue is not deployment model alone but whether the chosen model can support centralized identity management across hybrid estates without losing visibility or policy consistency. As SaaS, multicloud, and NHI populations grow, the architecture has to absorb more identities, more permissions, and more integration points at once.

That is typical of current enterprise decision-making: few organisations are choosing between pure on-premises and pure cloud, and most are really deciding how much governance strain their IAM programme can absorb before control degrades.


Key questions

Q: How should security teams choose between on-premises and cloud IAM?

A: They should choose the model that can prove control ownership, auditability, and lifecycle governance for their actual environment. The right answer depends on compliance burden, legacy integration fragility, cost of operating controls, and whether the team can centrally govern human and non-human identities across hybrid estates.

Q: Why do cloud IAM migrations often expose hidden identity risk?

A: Cloud migrations expose hidden identity risk because IAM is bound to trust relationships, connectors, and delegated access paths that are easy to miss until they fail. When those dependencies are undocumented or inconsistently governed, the migration turns into a control break rather than a platform change.

Q: What breaks when service accounts and permissions sprawl across hybrid environments?

A: Access reviews become incomplete, offboarding becomes inconsistent, and privileged credentials remain active long after teams believe they have been contained. That is how hybrid IAM drift turns into broader attack surface and audit failure, especially when non-human identities are not governed centrally.

Q: Who is accountable when IAM control gaps appear in cloud or on-premises models?

A: The organisation remains accountable regardless of deployment model, because outsourcing infrastructure does not outsource governance. Security, IAM, and platform teams need clear ownership for lifecycle controls, evidence collection, and third-party trust decisions before audit or breach conditions expose the gap.


Technical breakdown

Compliance requirements and control placement in IAM architecture

Compliance rarely determines a single correct IAM deployment model, but it does determine where controls are easiest to enforce. On-premises environments can simplify direct control over data residency, logging, and change management, while cloud environments can inherit certified controls from the provider if the architecture and operating model are aligned. The real issue is not where the platform lives but whether the organisation can prove segregation, auditability, and control ownership across the identity lifecycle.

Practical implication: map each regulatory requirement to the control location that can evidence it without manual workarounds.

Legacy integrations and hybrid identity dependencies

Legacy systems fail in cloud migrations because IAM is tied to dependency chains, not just authentication endpoints. When a cloud update breaks a connector, provisioning flow, or authentication trust relationship, the IAM issue is really an integration dependency failure. Hybrid estates make this harder because the identity plane has to coordinate old and new systems simultaneously, often with inconsistent protocol support and different operational cadences.

Practical implication: inventory integration dependencies before migration and classify which ones are brittle enough to block cloud-first IAM decisions.

NHI sprawl and centralized cloud identity management

The article correctly links cloud adoption with a larger identity sprawl problem, especially where non-human identities multiply faster than governance processes. Service accounts, API keys, and workload credentials often expand alongside SaaS and multicloud footprints, and centralized identity management becomes the only workable control plane for reducing policy drift. Without a unified strategy, access distribution fragments and review processes lose completeness.

Practical implication: treat NHI growth as a governance design constraint, not a side effect of cloud adoption.


Threat narrative

Attacker objective: The attacker objective is to exploit fragmented identity governance to gain durable access across hybrid environments and increase the blast radius of compromised credentials or mismanaged permissions.

  1. Entry begins when identity sprawl, legacy integration drift, or weak cloud governance creates unmanaged access paths across on-premises and cloud environments.
  2. Escalation follows when permissions, service accounts, or integration trust relationships are not centrally governed, allowing access expansion across systems and tenants.
  3. Impact is broader control failure, with identity-led breaches, audit gaps, and uncontained access spreading across hybrid estates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Hybrid IAM does not fail because cloud is inherently weaker. It fails when organisations assume a single governance model can preserve the same control quality across on-premises estates, SaaS, and multicloud. The article surfaces that tension clearly, and the practical conclusion is that control location matters less than control consistency across the full identity lifecycle.

Identity sprawl becomes a control-plane problem once non-human identities scale faster than human governance. The article’s point about NHI proliferation is the real structural issue here: cloud expansion adds service accounts, integration secrets, and delegated access faster than review cycles can keep up. That aligns with OWASP-NHI and NIST CSF thinking, and it means practitioners should judge architecture by how well it limits unmanaged identity growth.

Legacy dependency breakage is the hidden migration risk in cloud IAM decisions. Teams often treat migrations as platform changes, but IAM outages usually come from trust relationships and connectors that were never documented tightly enough. The implication is that migration planning must start with dependency mapping, not with product selection.

Control assurance matters more than deployment ideology. The article’s certification angle is a reminder that security outcomes depend on demonstrable control coverage, not on whether the platform is described as modern or traditional. Practitioners should evaluate whether the IAM architecture can produce evidence for audit, lifecycle governance, and least privilege without compensating manual processes.

From our research:

What this signals

Identity architecture decisions are increasingly lifecycle decisions. Once cloud and on-premises estates share the same user population, the same NHI footprint, and the same compliance burden, the programme fails or succeeds on whether governance is centralised enough to keep reviews, rotation, and offboarding consistent. The practical risk is not choosing the wrong deployment model, but allowing the control model to fragment before the estate does.

NHI sprawl makes deployment bias dangerous. A cloud-first posture can accelerate unmanaged service accounts unless the identity programme has explicit controls for discovery, ownership, and revocation. Teams should use the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 to align architecture decisions with identity reality rather than platform preference.


For practitioners

  • Map compliance to control ownership Document which IAM controls must remain directly managed on-premises and which can safely be inherited from cloud certifications, then test audit evidence for each requirement.
  • Inventory legacy identity dependencies before migration Catalogue every connector, trust relationship, and authentication dependency that could fail during cloud transition, then assign an owner for each brittle integration.
  • Centralise NHI governance across hybrid estates Bring service accounts, API keys, and workload credentials under one policy model so access review, rotation, and offboarding are not split across tools and teams.
  • Measure identity sprawl as a risk indicator Track the growth of non-human identities, permissions, and third-party access together, because architecture decisions become unsafe once governance cannot keep pace with expansion.

Key takeaways

  • The article’s central point is that IAM architecture should be chosen by governance fit, not by deployment fashion.
  • Hybrid estates and NHI growth make control consistency, not platform location, the deciding security issue.
  • Teams that cannot evidence lifecycle ownership across identities should treat their IAM design as incomplete, regardless of where it runs.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01The article centres on identity sprawl and governance gaps across hybrid estates.
NIST CSF 2.0PR.AC-4Least-privilege access governance is central to the article's architecture trade-offs.
NIST Zero Trust (SP 800-207)The article discusses centralized verification and access control across trust boundaries.
NIST SP 800-53 Rev 5AC-6Least privilege directly applies to the article's access control and sprawl concerns.
CIS Controls v8CIS-5 , Account ManagementAccount management discipline is needed for hybrid IAM and NHI governance.

Map hybrid IAM entitlements to PR.AC-4 and verify policy consistency across environments.


Key terms

  • Hybrid Iam Architecture: An IAM model that spans both on-premises and cloud environments under a shared governance approach. The key challenge is keeping policy, identity lifecycle controls, and audit evidence consistent when the underlying systems, connectors, and trust relationships differ.
  • Identity Sprawl: The uncontrolled growth of identities, permissions, and access paths across an environment. In hybrid estates this includes human users, service accounts, API keys, and workload credentials, which makes ownership, review, and revocation progressively harder to manage.
  • Non-Human Identity: A non-human identity is any machine or software identity that authenticates and authorises access, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. It must be governed with the same lifecycle discipline as human access, but often at a far larger scale.

What's in the full article

Soffid's full article covers the architecture-specific considerations this post intentionally leaves at a decision level:

  • Detailed comparisons of on-premises and cloud control trade-offs for regulated environments
  • Practical questions for assessing legacy system compatibility before cloud migration
  • Cost and operational burden considerations for teams planning long-term IAM ownership
  • The article's own view on centralized identity management in hybrid environments

👉 The full Soffid article expands the compliance, integration, cost, and sprawl questions behind the architecture decision.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 IAM governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org