Azure NHI governance in financial services: visibility, rotation, control

At a glance

What this is: A financial services case study shows that Azure NHI governance depends on discovery, risk prioritisation, and automated rotation working together.

Why it matters: IAM teams should read this as a reminder that NHI sprawl, stale accounts, and weak rotation logic can outpace manual governance across cloud and hybrid identity programmes.

👉 Read Oasis Security's case study on securing Azure NHIs in financial services

Context

Azure non-human identity governance breaks down when teams cannot see how many service principals, tokens, and related identities exist, or which ones still matter to the business. In this case, the private credit firm had expanded cloud operations faster than its ability to inventory and govern Azure AD NHIs, which created a visibility and remediation gap.

For financial services teams, the issue is not just scale. Azure NHI management becomes a governance problem when stale accounts, rotation timing, and policy exceptions are handled separately instead of as one lifecycle control set. That is the point at which risk becomes persistent rather than incidental.

Key questions

Q: How should security teams govern Azure non-human identities at scale?

A: Start with discovery, then add ownership, privilege review, and lifecycle state. Azure NHI governance fails when teams try to rotate or restrict identities they cannot fully see. The practical path is to maintain a current inventory, identify stale or high-risk identities, and connect remediation to business dependency so controls do not disrupt production.

Q: Why do stale service identities increase risk in cloud environments?

A: Stale identities extend the life of access beyond the business purpose that created it. That creates residual exposure, especially when privileges remain valid and nobody is actively watching usage. In cloud environments, dormant access often survives longer than the teams that own it, which makes cleanup and accountability essential.

Q: What breaks when NHI rotation is not tied to usage evidence?

A: Rotation without usage evidence can either miss risky identities or break legitimate integrations. If a team cannot tell whether an identity is still in service, it may rotate too late, too rarely, or in the wrong place. Effective NHI rotation depends on knowing what is active before changing secrets.

Q: What should compliance teams ask about Azure NHI governance during review?

A: They should ask who owns each identity, how stale accounts are detected, how rotation is triggered, and what evidence proves the lifecycle is controlled. For financial services, the key question is whether the organisation can explain identity state clearly enough to support audit, incident response, and change control.

Technical breakdown

Azure NHI auto-discovery and identity inventory

Azure NHI auto-discovery is the process of finding non-human identities across an environment and mapping where they are used. In practice, that means service principals, application registrations, tokens, and related accounts need to be discovered before they can be governed. The technical issue is not just count. Usage patterns, access points, and dependency paths determine whether an identity is active, dormant, or risky. Without an accurate inventory, access reviews become partial and rotation programmes miss the identities that matter most.

Practical implication: build a complete Azure NHI inventory before trying to optimise policy, rotation, or cleanup.

Risk posture analysis for non-human identities

Risk posture analysis turns raw identity inventory into prioritised remediation. It combines privilege level, activity, exposure, and lifecycle state so security teams can separate routine identities from those that need immediate action. In Azure environments, this is especially important because one stale service identity can remain valid long after the workflow that created it has changed. The control value comes from ranking identities by blast radius and current use, not by label alone.

Practical implication: rank Azure NHIs by exposure and privilege so remediation starts with the identities that can cause the most harm.

Automated credential rotation and stale account removal

Credential rotation for NHIs only works when it is tied to lifecycle state and operational dependency. If rotation happens without knowing whether the identity is still in use, teams either leave exposure in place or break production access. The same applies to stale account removal. Disabling an unused identity is a lifecycle action, but it must be backed by usage evidence and change awareness. In regulated environments, the practical challenge is proving that rotation and deprovisioning are controlled, not ad hoc.

Practical implication: connect rotation and stale-account cleanup to usage evidence so production dependencies are not broken accidentally.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

Azure NHI governance fails first as a visibility problem, not a rotation problem. The private credit firm did not start with a broken control so much as with an incomplete picture of what existed in Azure AD. That matters because lifecycle controls cannot be applied to identities that are not discovered. In NHI terms, inventory precedes entitlement hygiene, and entitlement hygiene precedes safe automation. Practitioners should treat undiscovered NHIs as ungoverned by definition.

Stale NHI persistence is the control gap this case makes visible. The article shows stale accounts being disabled only after discovery and risk analysis surfaced them. That is a familiar failure mode in cloud identity programmes, where identities outlive the workload or team that created them. The governance lesson is simple: access that outlives its operational purpose becomes residual risk, even when no one is actively using it. Practitioners should measure how long stale NHIs remain valid after they stop serving a business function.

Automated rotation changes the operating model, but only after lifecycle ownership is established. Rotation is not the point by itself. The point is that Azure NHI governance becomes repeatable when identity state, risk posture, and operational ownership are linked. That aligns closely with the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs. Practitioners should read this as a lifecycle governance problem, not a tooling feature.

Financial services adds regulatory pressure to an already difficult NHI problem. Private credit and similar firms need evidence that identities, privileges, and rotations are controlled in ways that can stand up to audit expectations. That makes the case relevant to both security and compliance leaders. If a team cannot explain which Azure NHIs are active, stale, or rotated, it is not just a security blind spot. It is also an accountability gap that will surface in review, incident response, or governance testing.

Oasis Security's four-stage model reflects a broader NHI maturity pattern. First comes deployment and integration, then discovery, then risk insight, then remediation and ongoing management. That sequence is useful because it mirrors how most organisations actually catch up with NHI sprawl. The practical conclusion is that teams should not expect policy maturity before visibility maturity. Governance only becomes scalable once the environment can be seen clearly enough to manage.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader lifecycle lens, the NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding fit into one control model.

What this signals

Azure NHI programmes usually fail by accumulation, not by one dramatic event. Once discovery surfaces stale identities and unmanaged access paths, the programme has to shift from one-off cleanup to ongoing lifecycle control. The operational signal is whether security and platform teams can keep ownership, usage, and rotation aligned as cloud estates expand.

With 97% of NHIs carrying excessive privileges, the risk is not just volume but blast radius. That figure from the Ultimate Guide to NHIs reinforces why Azure identity hygiene must be risk-ranked, not treated as a flat inventory exercise. Teams should expect auditors and incident responders to ask for proof of control, not just proof of discovery.

Identity lifecycle maturity now matters as much as cloud architecture. Where teams once focused on service deployment, they now need to prove that stale accounts are removed, rotations are executed, and dependencies are understood. Financial services programmes that cannot show that control loop will keep inheriting hidden access risk.

For practitioners

• Inventory Azure NHIs before enforcing policy Map service principals, application registrations, tokens, and other non-human identities to a current owner and usage state. Treat identities without a clear owner or activity record as priority candidates for review.
• Prioritise stale account removal by operational dependency Disable inactive identities only after confirming whether they still support scheduled jobs, integrations, or exception-driven workflows. Use dependency checks to avoid breaking business-critical access while removing dormant exposure.
• Tie credential rotation to lifecycle state Rotate credentials only when the identity is tracked, owned, and still required. Where possible, automate rotation for identities with stable dependencies and document the rollback path for critical workloads.
• Build risk-based remediation queues for Azure NHIs Sort identities by privilege, exposure, and business criticality so the team remediates high-blast-radius accounts first. Review these queues alongside access recertification and change management meetings.

Key takeaways

• This case shows that Azure NHI governance starts with visibility, because unmanaged identities cannot be remediated intelligently.
• The operational risk is persistent access, especially when stale accounts and outdated credentials remain valid after business use changes.
• Security teams should link discovery, ownership, rotation, and offboarding into one lifecycle process if they want control that holds up in production and audit.

Key terms

• Non-Human Identity: A non-human identity is any credentialed machine or workload identity used to access systems, data, or services. In Azure environments, this can include service principals, application registrations, tokens, certificates, and managed identities that must be owned, reviewed, and retired like any other access path.
• Identity Inventory: Identity inventory is the current record of which identities exist, what they do, and who owns them. For non-human identities, it is the foundation for governance because rotation, offboarding, and access review are ineffective when the estate cannot be fully seen.
• Stale Account: A stale account is an identity that still exists and may still authenticate, but no longer has a valid business purpose. In NHI programmes, stale accounts often outlive the workload or team that created them, leaving residual access that should be removed or tightly constrained.
• Credential Rotation: Credential rotation is the controlled replacement of a secret, token, or key so old material cannot be reused indefinitely. For non-human identities, rotation only works when it is linked to ownership, dependency checks, and lifecycle state, otherwise it can create either exposure or service disruption.

Deepen your knowledge

Azure NHI discovery, rotation, and offboarding are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme needs a stronger lifecycle model for cloud identities, it is worth exploring.

This post draws on content published by Oasis Security: How a Financial Service Institution Secures Azure NHIs with Oasis Security. Read the original.