Invisible Identity, Visible Liability

An NDGM analysis of Orchid Security’s Identity Gap: 2026 Snapshot, read against the UK regulatory landscape.
Nicholas Martin, NDGM

For the first time, the identities an enterprise cannot see outnumber the ones it can.

That is the headline finding of Orchid Security’s Identity Gap: 2026 Snapshot. Across the enterprise application estates Orchid analysed between April 2025 and March 2026, 57% of identity is invisible to the programmes meant to govern it, against 43% that is managed and visible. I have called this invisible majority “identity dark matter”: present, exerting force on everything around it, and absent from the dashboards.

For a UK security or compliance leader, that finding is more than uncomfortable — it is a regulatory problem. Britain spent 2025 absorbing a cluster of operational-resilience deadlines. The FCA’s regime reached the end of its transitional period on 31 March 2025; the EU’s Digital Operational Resilience Act began to apply from 17 January 2025. Every regime now in force assumes you can see, govern and evidence the identities operating your systems. Orchid’s data says that, on average, you can account for fewer than half of them.

This analysis takes Orchid’s six anchor statistics and maps them onto the four regulatory regimes that define identity risk for a UK enterprise today: UK GDPR, FCA operational resilience, DORA, and the UK’s NIS regime. To keep the mapping concrete rather than abstract, it runs the numbers through a single composite organisation.

The six numbers

Orchid’s Identity Gap: 2026 Snapshot draws on anonymised telemetry from enterprise applications across North America and Europe, spanning financial services, healthcare, retail, manufacturing and energy. Six findings anchor the report:

1. Invisible identity outweighs visible identity, 57% to 43%. The majority of enterprise identity is unmanaged — it sits outside the systems meant to govern it.
2. 67% of non-human accounts are created directly within the application, unseen and unmanaged by the organisation’s IAM programme.
3. 57% of applications bypass centralised identity providers — authenticating users locally, outside the IdP. (Two of Orchid’s findings carry the figure 57%; they measure different things.)
4. 70% of enterprise applications contain an excessive number of privileged accounts.
5. 40% of accounts are orphaned — still active after the people who owned them have gone.
6. 36% of credentials are hardcoded in clear text within applications.

I want to be transparent about why I find this report credible enough to build an analysis on. Industry surveys — CyberArk’s Identity Security Landscape among them — have put the ratio of machine to human identities at roughly 45 to 1. Orchid’s telemetry comes from a different method — application-layer instrumentation — and a different population of organisations, and it points in exactly the same direction: the identity estate is overwhelmingly non-human, and overwhelmingly unmanaged. When two independent measurements taken different ways agree, the prudent assumption is that they are describing something real.

The rest of this piece is about what “something real” costs you when a UK regulator asks to see it.

A composite firm: Pennine Mutual

Regulatory mapping is easy to wave at and hard to feel. So consider a single organisation.

Pennine Mutual is not a real company. It is a composite — a synthetic firm I have assembled from patterns I see repeatedly across UK financial-services identity estates. Pennine is illustrative; the proportions behind it are taken straight from Orchid’s report.

Apply Orchid’s figures to Pennine’s estate and the abstract becomes specific. Of roughly 520 applications, about 296 authenticate users outside the central identity provider. About 364 carry more privileged accounts than they need. And of the credentials scattered across that estate, more than a third — 36%, on Orchid’s numbers — sit hardcoded in clear text. The IAM team’s certification campaigns, joiner-mover-leaver workflow and access dashboards cover the 43% of identity that is visible — and, by Orchid’s measure, miss the 57% that is not.

And that is before counting the non-human identities. If Pennine’s estate resembles the ratios measured elsewhere, its 3,500 staff accounts sit alongside well over a hundred thousand service accounts, API keys, tokens and automation identities — two-thirds of them created inside applications, unmanaged, holding standing access.

Pennine, like most UK firms of its size, is not regulated by one rulebook. It is regulated by four at once.

Four rulebooks, one identity gap

UK GDPR, Article 32 — security of processing

Article 32 of the UK GDPR requires every controller and processor to put in place “appropriate technical and organisational measures to ensure a level of security appropriate to the risk.” It then names, among those measures, the ability to ensure the ongoing confidentiality and integrity of processing systems and — critically — “a process for regularly testing, assessing and evaluating the effectiveness” of the controls. Article 32(4) adds that anyone acting under the controller’s authority must process personal data only on instructions.

Orchid’s data describes an estate that cannot satisfy this. Credentials hardcoded in clear text — 36% of all credentials, by Orchid’s measure — are close to a textbook failure of “appropriate technical measures”: a credential in source code is, by definition, not protected. Orphaned accounts — 40% of the total — are standing access held by people no longer authorised to have it, which is precisely the situation Article 32(4) exists to prevent. And the 57% invisibility figure defeats the testing obligation at its root: you cannot regularly assess the effectiveness of access controls over identities you cannot enumerate. For Pennine, the question the ICO would ask is not “was there a breach” but “can you evidence that you governed access to members’ personal data” — and over most of the estate, the honest answer is no.

FCA operational resilience — PS21/3 and SYSC 15A

The FCA’s operational-resilience regime — set out in Policy Statement PS21/3, “Building operational resilience”, with the rules in chapter 15A of the Handbook’s SYSC sourcebook — requires firms to identify their important business services, set an impact tolerance for each (the maximum disruption the firm can absorb), and map the resources each service depends on: the people, processes, technology, facilities and information. Firms then test, through severe-but-plausible scenarios, that they can remain within tolerance. The transitional period ended on 31 March 2025; full compliance is now expected, not aspirational.

Mapping is where the identity gap bites. A resource map of an important business service is only as complete as the identity inventory beneath it — and an inventory that misses 57% of identity is not a map, it is a sketch. Non-human identities are not a footnote here: at Pennine, the overnight processes that move money, reconcile ledgers and generate member statements are operated by service accounts. An unmanaged service account is an unmapped dependency inside an important business service. The 57% IdP-bypass figure is worse still — each bypassed application is an access path into the business service that the firm cannot centrally monitor, suspend or revoke. And because 70% of applications are overprivileged, a single compromised credential breaches impact tolerance faster and wider than the firm’s scenario testing assumes. The regime is explicitly continuous: the obligation is to remain within tolerance, so a point-in-time clean-up does not discharge it.

DORA — for the parts of the firm that touch the EU

The Digital Operational Resilience Act does not apply in the UK. But it reaches UK firms in two ways. A UK group with EU-based financial entities — Pennine’s Dublin subsidiary is the example — is in scope for those entities. And a UK technology supplier serving EU financial firms can be designated a “critical ICT third-party provider” and pulled into DORA’s oversight regime directly.

For Pennine’s Irish subsidiary, DORA requires a documented ICT risk-management framework, and identity and access management sits at the centre of it. DORA expects strong authentication, least-privilege access, managed and regularly reviewed access rights, and lifecycle control over accounts — explicitly including non-human and technical accounts. Read Orchid’s six numbers as a DORA gap assessment and every one of them is a finding: IdP bypass undermines the authentication requirement; overprivilege and orphaned accounts breach least-privilege and access-review expectations; unmanaged non-human accounts are unmanaged ICT assets; clear-text credentials fail the most basic cryptographic-control test. DORA also requires firms to maintain registers of information and to monitor ICT risk continuously — both of which assume a complete identity picture the firm does not currently have.

The UK NIS regime and the Cyber Security and Resilience Bill

A point of precision first, because it matters for credibility: the UK does not have “NIS2”. NIS2 is an EU directive. The UK’s own regime is the Network and Information Systems Regulations 2018, and it is being overhauled — not by adopting NIS2, but by the Cyber Security and Resilience Bill, introduced to Parliament on 12 November 2025 and now progressing through its parliamentary stages, with phased implementation to follow once it becomes law.

A financial-services firm like Pennine is generally not a NIS “operator of essential services” — the FCA and PRA regulate its resilience instead. The NIS dimension reaches Pennine through its supply chain. The Cyber Security and Resilience Bill expands the regime to bring medium and large managed service providers and data-centre operators into scope, and introduces a “critical supplier” designation. Pennine’s MSPs and its colocation provider will become regulated entities; the security expectations placed on them — including identity controls — will flow back to Pennine through contracts and assurance. The identities that matter most in this regime are the cross-organisational, non-human ones: the service accounts and API credentials that stitch Pennine to its suppliers. Orchid’s 67% unmanaged-NHI and 36% clear-text-credential figures describe exactly that supply-chain identity surface. The Bill also tightens incident reporting — notification within 24 hours, a full report within 72 — and rapid reporting assumes you can rapidly attribute an incident to an identity. Across an estate that is 57% invisible, attribution is slow.

The agentic acceleration: how AI is growing the dark matter faster

Everything above describes the estate as Orchid measured it. The uncomfortable part is that the measurement is already ageing — because the fastest-growing category of identity in most estates barely existed twenty-four months ago.

Consider what has arrived on an ordinary corporate laptop in that time. Local AI assistants and copilots, installed by developers and analysts to speed up their own work. MCP servers — the plumbing that lets an assistant reach into email, code repositories, databases and internal APIs — each configured with standing credentials so the assistant can act without asking. Agent frameworks holding API keys for the models and services they orchestrate. And, behind each of these, service accounts minted per agent, because everything that acts needs something to act as. None of this is hypothetical. It is how AI tooling actually gets adopted: one developer, one config file at a time, with no procurement gate and no identity process anywhere in the path.

The delivery mechanism for most of it is the humblest one imaginable: plain text on developer endpoints. API keys pasted into dotfiles. Database passwords in .env files that were only ever meant to be temporary. Tokens sitting in shell histories because someone exported them inline. Credentials embedded in tool configuration files no inventory has ever read. These secrets live outside every identity provider and outside every vault — and, crucially, outside the reach of server-side discovery. An application-layer scan of the kind behind Orchid’s data will find the local account inside the application; it will not find the copy of that account’s credential sitting in a config file on a laptop. This is the dark matter’s dark matter: identity that not only bypasses governance, but bypasses the instruments we use to measure the bypass.

And the gap widens rather than stabilises, because these identities are created at developer speed, not IT speed. A new MCP server is a five-minute edit to a config file; nobody raises a ticket, nobody registers an account, nobody sets an expiry. There is no joiner-mover-leaver process that covers an MCP server. When the developer who wired it up moves teams or leaves, the credential stays behind and keeps working — the orphaned-account problem replayed on a surface no certification campaign has ever touched. Governance processes built to run at the pace of HR events cannot keep up with identities that are born in the time it takes to save a file.

The regulatory read-across is direct, and it follows the same lines drawn earlier in this paper. The FCA’s resilience regime expects firms to map all the resources an important business service depends on. The logic applied above to unmanaged service accounts applies unchanged: an agent holding standing access to systems inside that service is an unmapped dependency, invisible to the firm’s scenario testing.

DORA’s Article 9 access-management expectations run the same way. The framework requires access rights to be managed, reviewed and controlled across the lifecycle, and — as noted earlier — it does not exempt non-human and technical accounts. An agent holding an API key is an ICT asset with access rights. The obligation to govern those rights does not lapse because the holder is a piece of software rather than a person; if anything, the long-lived, unrotated nature of agent credentials makes the lifecycle requirement bite harder.

And under UK GDPR, the accountability principle requires a controller to be able to demonstrate compliance — which starts with knowing what processes personal data. A local assistant with a database credential processes personal data. An agent wired into a CRM through an MCP server processes personal data. If those processes appear in no record and no one can say what they access, accountability fails at the first question the ICO would ask, before any assessment of the controls themselves.

What does adequate control of this surface look like? Three properties, in sequence. First, continuous discovery at the edge — on the endpoints where these identities are born, because no server-side scan will ever see them. Done properly, edge discovery is metadata-only and read-only: it records that a credential exists, what kind it is and where it sits, and never the secret’s value or the surrounding file contents — privacy-preserving by construction, not by policy. Second, identity-first triage. The question that matters is not “what does this file contain” but “who or what does this credential empower, over which systems, with what privilege” — the same ownership-and-scope discipline the rest of the estate already demands. Third, enforcement: rotate the exposed credential, vault the sprawled secret, decommission the agent identity nobody owns — each action leaving the same evidential record the rest of the estate is already required to produce.

It is worth being explicit about what this is not: it is not data loss prevention. Inspecting the content of documents leaving the estate is a different control for a different problem. The problem here is identity — credentials with scope, held by software that acts — and it needs an identity-governance answer, not a content-inspection one.

The agentic estate, in other words, faces exactly the test the rest of this paper has been applying: not “did you find it once”, but “can you evidence, continuously, that it is governed”.

The common thread: discovery is not governance

That closing test is not peculiar to the agentic estate. Read the four rulebook sections again and it is the structural point every one of them makes: none of these regimes asks only “is it secure right now?” — every one of them asks “can you evidence, on an ongoing basis, that it is governed?”

UK GDPR Article 32 demands a process for regularly testing and evaluating effectiveness. FCA operational resilience demands that firms remain within impact tolerances and demonstrate it through repeated testing. DORA demands continuous ICT risk management, maintained registers and a testing programme. The Cyber Security and Resilience Bill demands ongoing security measures and fast incident attribution. The common verb is not find — it is govern, and evidence.

This is the distinction that decides whether the identity gap is an expensive problem or a manageable one. Discovering the gap — scanning the estate, producing the report, learning that 57% of your identity is invisible — is necessary and valuable. Application-layer discovery of the kind behind Orchid’s data is genuinely hard to do, and it is how you find identity that never touched the IdP and therefore never appeared in any prior inventory. But discovery is a diagnosis. A scan that tells you 296 of your applications bypass the IdP has not revoked a single unnecessary credential, assigned a single owner, or produced a single piece of evidence an auditor can rely on. The regulation is not satisfied by knowing. It is satisfied by governing — and by being able to prove it.

What closing the gap actually looks like

If discovery is the diagnosis, governance is the treatment — and for an estate the size of Pennine’s, it has to be a repeatable system rather than a project. In practice it is five steps.

• Discover completely. Visibility has to include the invisible 57% — which means discovery at the application layer, not just a re-read of what the IdP already knows.
• Attribute ownership. Every identity, human and non-human, needs a named, accountable human owner. For the long tail of unowned service accounts, ownership has to be inferred and proposed — from access patterns and deployment context — because no team will hand-catalogue a hundred thousand of them.
• Govern the lifecycle. Joiner-mover-leaver discipline for people; for non-human identities, a rotation cadence, an expiry, and automatic quarantine of anything unowned or long-inactive. This is where orphaned accounts and stale credentials are eliminated rather than counted.
• Certify on a cadence. Access reviews that conclude in enforced revocation, not a signed-off spreadsheet — quarterly where the regulator or the risk demands it.
• Evidence everything. Every framework above ultimately asks you to prove it. That means immutable, time-stamped, tamper-evident records of who had access to what, who approved it, and when it was removed.

In architectural terms, that means a live identity graph that holds human and non-human identities together, lifecycle policies that govern the non-human estate, and certification that leaves an audit-ready evidential record. There is more than one way to assemble these five steps, and I am not going to pretend otherwise. But the sequence itself is not optional — it is, in effect, what the UK rulebook now describes when you read its identity requirements end to end. Discovery platforms and governance platforms are two halves of one control objective: one finds the gap, the other closes it and proves it closed.

The bottom line for UK leaders

In 2025 the UK’s operational-resilience deadlines arrived. In 2026 the data arrived to tell us how ready we were — and the answer, on identity, is “less than half ready,” because less than half of the identity estate is even visible.

Invisible identity is no longer a security-hygiene footnote. Under UK GDPR, FCA operational resilience, DORA and the incoming Cyber Security and Resilience Bill, it is a board-level regulatory liability — an un-evidenceable control environment sitting underneath services the firm is legally required to be able to govern. The organisations that come through the next round of regulatory assessment well will be the ones that stopped treating identity as a directory and started treating it as a governed, evidenced lifecycle — humans and non-humans alike.

This analysis draws on Orchid Security’s Identity Gap: 2026 Snapshot. The statistics are Orchid’s; the regulatory mapping and the Pennine Mutual composite are the author’s. It is commentary, not legal advice — your firm’s obligations depend on its specific permissions, footprint and service profile.

This paper is analysis, not legal advice. A PDF edition is also available for download or offline reading: NDGM-identity-dark-matter.pdf.