Who should own the decision to deploy identity infrastructure on premises versus in public cloud?

Why This Matters for Security Teams

The ownership question is really a control question: who decides where identity enforcement lives, who accepts the risk, and who can prove the environment meets regulatory and resilience requirements. For non-human identities, that decision affects secrets handling, audit scope, recovery design, and blast radius. NHIs are already a dominant exposure class, and NHI Management Group’s Ultimate Guide to NHIs shows why teams cannot treat deployment location as a simple infrastructure preference.

Security teams often underestimate how much the hosting model changes control boundaries. Public cloud can accelerate managed services, elasticity, and policy automation, while on premises can simplify sovereignty, residency, or customer-specific constraints. Neither option is inherently safer. What matters is whether the operating model can support least privilege, rotation, logging, segregation of duties, and rapid revocation in the event of compromise. NIST’s SP 800-53 Rev. 5 is useful here because it frames the control objectives, not the vendor preference.

In practice, many security teams encounter platform-led deployment decisions only after residency gaps, overbroad admin access, or audit findings have already created exposure rather than through intentional governance.

How It Works in Practice

Ownership should sit with a joint decision group made up of security, identity, architecture, compliance, and infrastructure leadership. That group defines the decision criteria first, then engineering executes the chosen pattern. The criteria should include data sovereignty, regulatory obligations, integration with enterprise directories, key custody, backup and recovery, latency, high availability, and the team’s ability to operate patching and incident response consistently.

For identity infrastructure, the practical difference is not just where servers run. It is where trust anchors, signing keys, secrets stores, policy engines, and audit records are controlled. Public cloud often works well when the organisation can use mature managed controls, region pinning, and strong separation of duties. On premises often fits when legal or contractual constraints require tighter physical control or when an existing resilience design already depends on internal recovery processes. Best practice is evolving, but the decision should always be tied to the control model in Top 10 NHI Issues and to the lifecycle problems documented in the Ultimate Guide to NHIs.

• Define which data, keys, and logs can leave a jurisdiction, and which cannot.
• Require the same minimum control set in either deployment model, including rotation, backup, and offboarding.
• Document who approves exceptions, who owns recovery, and who signs off on audit evidence.
• Separate platform operations from policy authority so implementation cannot silently redefine risk acceptance.

Where public cloud is chosen, identity services should be evaluated for tenant isolation, region support, key management options, and revocation speed. Where on premises is chosen, teams should verify whether they can keep pace with patching, redundancy, and forensic logging without creating brittle manual processes. These controls tend to break down when the organisation has multiple business units making independent deployment choices because policy drift and inconsistent recovery assumptions quickly follow.

Common Variations and Edge Cases

Tighter control over identity infrastructure often increases operational overhead, requiring organisations to balance sovereignty and assurance against speed, staffing, and resilience economics. That tradeoff becomes sharper when identity systems support many applications, external partners, or autonomous workloads that need short-lived access and high availability.

Some environments need a hybrid answer. A common pattern is to keep policy authority, root trust material, or regulated audit data in one environment while running less sensitive runtime components elsewhere. Another variation is to place identity services in public cloud but require customer-managed keys, private networking, and region-specific deployment guardrails. There is no universal standard for this yet, so governance should document the acceptable pattern rather than assume one deployment model is always preferable.

Edge cases also arise when a merger, sovereign cloud mandate, or legacy directory dependency limits options. In those situations, the decision owner should still be the same cross-functional governance group. Infrastructure teams can recommend the technically cleaner path, but they should not be the sole risk owner. A single platform team making that call can leave compliance, audit, and business continuity obligations underexplained until a review or incident exposes the mismatch.

When the organisation cannot prove revocation, failover, and evidence retention in the chosen model, the deployment choice is not ready for production governance.

Related resources from NHI Mgmt Group

• Why does identity risk increase when on-premises and cloud identity systems are tightly connected?
• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?
• How should public sector organisations evaluate identity security controls for cloud services under GovRAMP or similar frameworks?