Identity programmes have spent a decade getting human access right: single sign-on, multi-factor authentication, joiner-mover-leaver processes, access reviews with an owner who signs. That work is largely done in mature organisations, and it covers a shrinking share of what actually authenticates against your systems. Service accounts, integration users, application credentials, automation runners and now assistants acting on somebody's behalf outnumber employees in most estates, frequently by a wide margin. Almost none of them have an owner, an expiry date, or a review.
Your leaver process removes a person's access on their last day. Nothing removes the integration account they created in 2019 for a supplier portal that was decommissioned in 2022
This is the year that stops being a housekeeping problem, because the number of non-human identities is now growing faster than anybody's ability to enumerate them.
Four distinct populations, not one
They get lumped together under machine identity and they need different treatment. Service accounts. Long-lived, often over-privileged, frequently shared between systems, and regularly holding a password in a script somewhere. The oldest problem and still the largest. Application and workload credentials. Certificates, keys and tokens used by systems to authenticate to each other. Better handled where a platform manages them, dangerous where they were issued manually and nobody tracked the expiry. Automation and integration users. Created by a business team for a specific connection, usually with broad permissions because narrow ones were harder to configure, and outliving the project that needed them. Delegated agent identities. New, and structurally different: software acting with a named person's authority. The critical question is whether the action is recorded as the person's or the system's, and whether the permission is the person's full set or a subset. That last population is where the current risk concentrates, because the tooling to constrain it is younger than the enthusiasm for deploying it.
| Identity class | Review focus |
|---|---|
| Service account | Owner, privilege and standing-secret custody |
| Workload credential | Issuance, expiry, rotation and platform management |
| Automation or integration user | Continued need and permissions for its specific connection |
| Delegated agent | Named human principal, narrower authority and chain attribution |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The controls that actually apply
An owner for every identity, recorded. Not a team, a named person. This is unglamorous and it is the foundation, because every other control needs someone to ask. Expiry by default. Every non-human credential should have an end date requiring renewal. The renewal request is the review; if nobody can say why it exists, it lapses correctly. Scoped permissions, verified against actual use. Compare what an identity is permitted to do against what it has done in ninety days, and remove the difference. This is one of the highest-yield exercises available and most organisations have never run it. No shared secrets in code or configuration. Vault, rotate, and remove the standing value. The practice is well understood; the coverage is poor. Attribution through the chain. When an agent acts for a person, the log must show both. Systems that record only the service account destroy the accountability trail at exactly the point you will need it. Inventory before anything else. You cannot govern what is not enumerated, and enumeration takes longer than expected because these identities live in places no central directory sees.
Where to start if you start this quarter
Enumerate, assign owners, set expiry on everything new, and run the permission-versus-use comparison on the twenty highest-privilege non-human identities you have. That last step alone typically removes a meaningful amount of standing risk in a fortnight.
Practical Guidance for Machine Identity Assessment
- Enumerate every non-human identity before designing any control.
- Assign a named owner to each one, not a team.
- Set expiry by default so review happens through renewal.
- Compare permissions to ninety days of actual use.
- Remove standing secrets from scripts and configuration.
- Log the person behind the agent, not just the account.
- Treat delegated agent identities as a separate class with tighter limits.
- Include non-human identities in the access review cycle.
The Regional Angle
The first issue here is the implementation partner, which is the dominant source of orphaned privileged identities in regional estates. Enterprise deployments across the Gulf are typically delivered by a systems integrator whose consultants need administrative access during the project, create service accounts for interfaces and data loads, and then demobilise. The accounts remain, often with elevated rights, sometimes with credentials known to individuals who have since left the partner and occasionally the country. A specific and immediately useful exercise: list every privileged identity created during your last two implementation projects, establish which are still needed, and put the rest through a controlled removal. Then write credential handover and revocation into the next statement of work, because it is almost never there. The second concerns group structures, which multiply this problem in a way single-entity organisations do not experience. A regional group with entities across several Gulf states commonly runs shared systems accessed by separate legal entities, with integrations between an operating company in one jurisdiction and a holding entity in another, each built at a different time by a different party. The integration accounts crossing those boundaries carry data between entities whose regulatory obligations differ, and nobody owns them because they belong to the connection rather than to either side. Assign ownership at the group level for every cross-entity integration identity specifically, since these are both the hardest to attribute and the most consequential when a regulator asks who moved what. The third is about the regulatory frameworks now landing on this, which are more prescriptive than many organisations expect. The Saudi national cybersecurity controls, the Emirati information assurance standards and the various financial services frameworks in the region all contain requirements around privileged access management, credential lifecycle and accountability that apply perfectly well to non-human identities, even where the drafting had people in mind. Auditors here are beginning to ask for the service account inventory as a matter of course. Producing one reactively during fieldwork is painful; producing it now and maintaining it is a modest ongoing cost that also happens to remove real risk.
The objection worth taking seriously
The strongest objection is that this is a governance exercise being sold as a security programme. The genuinely dangerous credentials are a small number of highly privileged ones, and those are usually already known to the security team; the rest of the inventory is thousands of low-privilege accounts reading a calendar or posting to a channel. Building a full enumeration, an ownership register and an expiry regime across all of it consumes months of effort, produces a spreadsheet, and delivers most of its risk reduction in the first two weeks of work on the top twenty accounts. The remainder is compliance theatre with a lifecycle diagram. That is largely right about where the risk sits, and the advice to start with the top twenty is exactly why it appears above. Where the argument breaks down is in assuming the privilege level is stable and known. It is not. The recurring pattern in these incidents is an identity that was genuinely low-privilege when it was created and acquired more over four years, as someone added a permission to fix a failing job at eleven at night and never removed it. Nobody reviewed it because nobody owned it, and it did not appear on the security team's list of dangerous accounts because it was not dangerous when the list was made. The inventory is not valuable as a document; it is valuable because it creates the owner who receives the renewal prompt. Build it incrementally, start with the accounts that matter, and accept that the long tail is where the next one will come from.
Common Questions
Should agents get their own identity or use the person's?
Their own, with the person recorded as the principal on whose behalf they act, and a permission set narrower than the person's. Reusing human credentials destroys both attribution and containment.
How short should machine credential lifetimes be?
As short as the system tolerates without operational fragility. Short-lived issued credentials are strongly preferable to long-lived stored ones wherever the platform supports them.
Who owns a shared integration account?
One named person, chosen deliberately, usually on the consuming side. Shared ownership reliably means no ownership.
What should we expect over the next twelve months?
Expect non-human identity counts to keep climbing sharply as assistants and integrations proliferate. Expect the identity vendors to ship agent-specific delegation features, and expect early versions to be coarse. Expect at least one significant breach traced to a forgotten integration credential, as in most recent years. And expect auditors to start requesting the service account inventory by default.
Machine Identity Assessment — we enumerate what authenticates against your systems, find who owns it, and remove what nobody can justify.