Machine identity in banking: the accounts nobody onboarded

Anything that authenticates without a person at the keyboard: service accounts that run batch jobs, API keys between internal systems and toward a provider, TLS certificates that let two services trust each other, workload identities in a container platform, the credentials behind a chatbot or a reporting robot. OWASP's Non-Human Identities Top 10 describes these as application identities needing identification in production and names service accounts, API keys, access keys, encryption keys, tokens and certificates as the examples.

That OWASP list is worth reading as an inventory of how these fail, because its entries are operational and not theoretical: improper offboarding of unused accounts and keys, secret leakage into places that were never meant to store them, overprivileged identities, long-lived secrets whose expiry is distant or absent, the same identity reused across development, test and production, and humans using a service account for manual work. NIST SP 800-207 treats workload identity as a first-class subject in a zero trust architecture for the same reason.

The governance question is not which product manages these credentials. It is who, by name, is accountable for each one. A credential with a named owner gets reviewed, gets its permissions cut back when the job changes, and gets switched off when the system it served is decommissioned. A credential whose owner left in 2019 does none of those things, and it keeps working, which is the problem.

The ownership point is the core of the account of securing banking enterprises as non-human identities grow, and it is a governance hook and not a purchase. The review cycle is the same one that applies to employee access rights, which is where the EBA guidelines on ICT and security risk management put the expectation on access rights management. Zero trust in banking covers the architecture these identities sit inside.

A bank cannot manage what it counts as one blob. The types behave differently: a service account has a password and a permission set, an API key is a bearer token that works for anyone holding it, a certificate has an expiry date and a chain of trust, a workload identity is issued dynamically and may live for minutes. Each needs a different control, and treating them all as "credentials" produces a policy that fits none of them.

The ratio of machine to human identities and its direction, with the credential types involved, is the subject of this account of the machine identity problem. The practical use of a taxonomy is that it tells you which control to build first: a short-lived workload identity needs issuance machinery, while a long-lived API key in a vendor integration needs rotation and a plan for the day it leaks.

The most common way machine identity hurts a bank has nothing to do with an attacker. A certificate reaches its expiry date, two services stop trusting each other, and a payment interface or a customer channel goes down, usually outside office hours, usually with nobody on call who knows which certificate it was.

That makes inventory and agility the same project. You cannot renew what you have not found, and you cannot replace an algorithm across an estate you cannot enumerate, so the certificate inventory serves both the availability case and the cryptographic one. Cryptographic agility in finance covers the algorithm side, and the BSI guidance on cryptographic mechanisms is the German reference for what the certificates should contain.

An agent that reads a mailbox, queries a system and drafts a reply needs an identity like any other workload. An agent that can initiate a payment, change a limit or release a hold needs three things: an identity of its own, a mandate that states what it may do with explicit limits, and a trail from each action back to the person accountable for it.

The last one is the part that is easy to lose. An agent acting under a policy a human set does not remove that human's accountability, which is the argument in the case that AI agents depend on human identity governance. The EU AI Act requires human oversight for high-risk systems, so for a bank the accountability chain is a legal requirement and not an engineering preference. AI agents in finance covers what these agents do, the EU AI Act in finance the regulation, and AI compliance in Germany how BaFin approaches it.

This is not an unregulated frontier waiting for a rule. DORA requires ICT risk management, protection measures including access rights and identity management, and policies covering cryptographic controls and key management, and none of those provisions distinguishes between a credential a person uses and one a service uses.

So an estate of unowned service accounts is a finding today, not a risk for a future supervisory cycle. DORA in Germany covers the regulation, cybersecurity in German finance the wider security picture, and open banking in Germany the interfaces where many of these credentials cross an institutional boundary.

Start with the credentials that can move money or reach customer data, and give each one a named owner, a documented purpose and an expiry. That is a short list compared with the full estate, and it is the list an incident would be about.

Then attack the classes that cause the recurring pain: certificates with no renewal process, secrets sitting in code repositories and configuration files, and accounts whose last recorded use predates the current platform. AI in banking in Germany covers the direction that keeps adding to the count, which is the reason to get the process right before the volume arrives.

Any credential that authenticates to a system without a person at the keyboard: a service account, an API key, a TLS certificate, a workload identity in a container platform, a bot credential. OWASP calls these non-human identities and treats them as application identities that need identifying in production.

Because every integration, service, job and automation creates at least one, while a person creates one. Microservice architectures, cloud platforms and vendor integrations each multiply the count, and almost nothing removes them, since decommissioning a system rarely includes revoking the credentials it used.

Yes, and sharing a human's credential is the design to avoid, because the audit trail then says a person did something they did not do. The agent needs its own identity, a mandate with explicit limits on what it may do, and a recorded link to the person accountable for its actions, which the EU AI Act's human oversight requirement makes a legal matter for high-risk uses.

Yes. DORA's requirements on ICT risk management, protection measures, access rights and identity management, and cryptographic controls and key management do not distinguish between human and machine credentials, so an unowned service account or an unmanaged certificate estate is in scope of the existing duties.