NHI governance in financial services

What is actually different in this sector

Most NHI guidance generalises across industries because the technical problem does generalise. Three things here do not.

You are examined, not just audited. A supervisor can ask direct questions about specific dependencies and expect specific answers. That changes the standard of evidence from "we have a control" to "show me this control operating on this dependency on this date".

Availability failures are reportable. In most sectors an expired certificate is an outage. In a regulated financial entity, an outage in a critical function has notification obligations attached. That makes certificate lifecycle management a resilience matter rather than an operations one, and it is the framing that gets it funded.

The estate is older. Payment rails, core banking and settlement systems predate every mechanism in a modern workload identity architecture, and they cannot be replaced on a security timetable.

DORA and the register of information

DORA requires financial entities to maintain a register of contractual arrangements for ICT services, and to manage third-party ICT risk across the lifecycle including exit. See our DORA mapping.

The non-human identity consequence is direct. Every ICT provider with access to your systems holds a credential, and that credential has a scope, a lifetime and an owner, or it does not. Three questions follow from the register that most entities cannot answer immediately:

• Which credentials does each registered provider hold, and with what scope? The register records the contractual arrangement. It rarely records the technical access.
• What happens to those credentials on exit? Exit strategies are a DORA requirement. A documented exit that does not enumerate credential revocation is incomplete, and the enumeration is usually missing.
• Can you evidence that access was proportionate? This is the authority ratio question in supervisory language.

Reconciling the register against actual credential grants is the single most useful piece of work available in this sector, because it produces evidence for an obligation you already report against rather than creating a new workstream.

Model governance meets agent identity

Financial services has run model risk governance for decades. Model inventories, validation, approval, monitoring and periodic review are established practice with supervisory expectations attached.

That is a significant advantage and it is frequently wasted. Firms build a separate AI governance programme when the existing model governance structure already provides the inventory, the approval gate and the periodic review. What it does not provide is the identity layer: which credential the model or agent holds, what it can reach, and whose authority it acts under.

The efficient move is to extend rather than parallel. Add identity fields to the model inventory record, add an identity and delegation check to the approval gate, and add credential scope to the periodic review. Supervisors recognise the vocabulary, the governance forum already exists, and the marginal work is small. See agent registries for the fields that matter and delegation chains for the record an examiner will eventually ask for.

The legacy estate problem

Mainframes, payment switches, market data feeds and settlement interfaces frequently authenticate with static credentials, sometimes shared, sometimes unchanged for years, and often with no mechanism to rotate without an outage window that the business will not grant.

Pretending otherwise produces a policy nobody follows. What works:

1. Enumerate and classify explicitly as a known-incomplete segment with a named owner, rather than leaving it out of the inventory.
2. Front where possible. A terminating proxy holding the modern credential removes the legacy system from the credential path without touching it.
3. Compensate where not. Network restriction, monitoring and a documented exception with a review date and a named approver.
4. Attach to the refresh cycle. These systems get replaced eventually. Identity requirements written into the replacement programme cost nothing now and save the same conversation in five years.

Where to start

1. Reconcile the DORA register against actual credential grants. Direct evidence for an existing obligation.
2. Certificate expiry across critical functions. Availability is reportable, and the contracting lifetimes give the work a date.
3. Extend model governance to cover agent identity rather than building a parallel programme.
4. Classify the legacy estate as a documented exception segment with owners.
5. Measure revocation time on a third-party credential. Supervisors ask about containment, and the answer should be a number.

Frequently asked questions

What makes non-human identity different in financial services?

Three things. Supervisors examine specific third-party ICT dependencies directly, which raises the evidence standard from having a control to showing it operating on a named dependency. Availability failures in critical functions carry notification obligations, so an expired certificate is a resilience matter rather than an operational one. And the estate includes payment and settlement systems that predate every modern workload identity mechanism.

How does DORA apply to non-human identities?

Not by name. DORA requires a register of contractual arrangements for ICT services and lifecycle management of third-party ICT risk including exit. Every registered provider with access holds a credential, so the register creates three answerable questions most entities cannot answer immediately: which credentials each provider holds and at what scope, what happens to them on exit, and whether the access was proportionate. Reconciling the register against actual grants is the highest-value work available.

Should financial firms build a separate AI governance programme?

Usually not. Model risk governance already provides a model inventory, an approval gate and periodic review, with supervisory expectations attached and a governance forum that exists. What it lacks is the identity layer. Adding identity fields to the inventory record, an identity and delegation check to the approval gate, and credential scope to the periodic review is far cheaper than a parallel programme and uses vocabulary supervisors recognise.

How do you handle legacy systems that cannot rotate credentials?

Enumerate and classify them explicitly as a known-incomplete segment with a named owner rather than omitting them, front them with a terminating proxy where possible so the legacy system leaves the credential path without being modified, compensate with network restriction and monitoring plus a documented exception carrying a review date and named approver where fronting is impossible, and write identity requirements into whatever replacement programme already exists.

What should a financial services firm do first on non-human identity?

Reconcile the DORA register of information against actual credential grants, because it produces evidence for an obligation already being reported against rather than creating a new workstream. Then certificate expiry across critical functions, since availability is reportable and contracting certificate lifetimes give the work a fixed date.