The Workforce Without Contracts: Board Governance of Non-Human Identity

For most UK boards, identity governance still begins and ends with people. Joiners, movers and leavers are tracked through human resources; access reviews are scheduled; starters and exits have named owners. The logic is familiar and, in principle, sound.

The estate that sits beside that human workflow is less familiar. Service accounts keep integrations running. API keys connect products and partners. Bots execute routine tasks. OAuth tokens allow applications to act on a user's behalf long after the user has moved on. These non-human identities often outnumber staff, and many have no clear business sponsor, no documented purpose and no natural exit date.

That is not simply an infrastructure detail. It is a governance exposure with a technical expression. A credential that cannot resign, cannot be interviewed at exit and cannot explain its own purpose is a credential that must be governed deliberately.

Why machine identity has reached the board agenda

Automation is now central to how UK organisations operate. Cloud platforms, software as a service, payment integrations, data pipelines and customer-facing applications all depend on machine-to-machine access. Artificial intelligence tools add another layer: agents and integrations may hold delegated permissions to read data, trigger workflows or act on a user's behalf.

Attackers understand this. Human credentials are protected by familiar controls such as multi-factor authentication, conditional access and security awareness training. Non-human credentials are often protected by nothing more than a secret stored in a configuration file, a shared repository or a supplier's portal. They may be long-lived by design. They may be over-privileged because restricting them would have delayed a project. They may be invisible to the service desk because no person ever calls to reset their password.

Regulatory expectations reinforce the point. UK GDPR accountability requires organisations to demonstrate appropriate technical and organisational measures. Operational resilience regimes in regulated sectors expect firms to understand important business services and the dependencies that support them. Supply chain assurance increasingly turns on whether third parties can prove who, or what, is accessing systems and why. The board does not need to administer those controls, but it does need to know whether they exist.

The illusion of an inventory

Many organisations believe they have an asset register. What they often have is a register of the assets someone remembered to document. Non-human identities are frequently created outside formal procurement or change processes. A developer requests a key for a proof of concept. A marketing team connects a analytics tool through an OAuth consent screen. A supplier installs an integration with a service account that is never reviewed again.

The result is a familiar board problem: the organisation is managing the risks it can see, while the most durable access paths sit in the gaps between systems. The first board question is therefore not 'how many non-human identities do we have?' It is 'who can answer for each one?'

A board framework in five parts

A workable governance model does not require directors to understand token scopes in detail. It requires them to insist on five disciplines and to ask for evidence that those disciplines are operating.

1. Named ownership

Every non-human identity should have a business owner and a technical custodian. The business owner confirms that the identity still serves a purpose, that its access remains appropriate and that it will be reviewed on a defined cycle. Ownership by a team is weaker than ownership by a named role. Ownership by nobody is the condition most attackers prefer.

2. Constrained privilege

Machine identities should receive the minimum access needed for their function, with scope limits, separation of duties and no standing administrative rights unless there is a documented exception. Shared credentials should be treated as a control failure, not a convenience. The board should expect a register of the most privileged non-human accounts and a clear explanation of why each one needs that power.

3. Lifecycle rules

Human access follows a joiner, mover and leaver process. Non-human access needs an equivalent. Credentials should be created through a controlled route, expire by default, be rotated on a schedule and be removed when the application, supplier relationship or project ends. Recertification should be tied to the service lifecycle, not to the calendar alone. An identity that has no end date should require explicit approval.

4. Monitoring expectations

The organisation should be able to detect unusual authentication by a machine identity, the creation of new credentials, changes to privilege and access from unexpected locations or at unexpected times. Monitoring without a response path is theatre. The board should ask who receives the alert, what the analyst is expected to do and how quickly containment can begin.

5. A tested containment plan

Automation can become an attack path. A compromised integration may be used to move data, approve payments or alter records. The organisation therefore needs a containment plan for non-human identities: how to disable a credential, revoke a token, isolate an integration and maintain business continuity while the issue is investigated. A kill-switch that has never been tested is a diagram, not a control. Boards should ask when containment was last rehearsed and what dependencies were discovered.

What the board should ask for

Useful board questions are specific enough to produce evidence and broad enough to avoid micromanagement. Directors can ask:

• What proportion of critical services depends on non-human identities, and how complete is our inventory of them?
• Which non-human identities have privileged access, and who has approved that privilege in the past twelve months?
• How many credentials are orphaned, shared or past their review date?
• Who can create a new API key or service account, and what approval is required?
• When was the containment plan for a compromised automation last tested, and what failed?
• What assurance has internal audit or an independent tester provided over these controls?

Assurance without micromanagement

The board's role is not to become the identity administrator. It is to set risk appetite, require ownership and challenge the evidence. Non-human identity should appear in the risk register, in incident scenarios and in supplier assurance conversations. It should also feature in the questions put to management during cyber insurance renewal and in any post-incident review, because the same weakness that allows an attacker to persist can delay recovery.

Treat machine identities as a workforce without contracts. They need sponsors, limits, reviews and exits. A board that applies that simple discipline will not eliminate the risk, but it will make the organisation far harder to inhabit quietly.