FusionAuth’s survey of 300+ technology and security leaders argues that AI adoption has outpaced identity controls: widespread AI, shadow AI and non-human identities are creating new access risks.

by ChatGPT-5.6

Summary: FusionAuth’s survey of 300+ technology and security leaders argues that AI adoption has outpaced identity controls: widespread AI, shadow AI and non-human identities are creating new access risks, while policies and high confidence do not necessarily translate into fewer incidents.

For AI users and organizations, the practical lesson is to treat every AI agent as a governed identity—using least-privilege access, strong tenant isolation, credential controls, audit trails, monitoring and rapid revocation rather than relying mainly on governance documents.

The report raises important issues but should be interpreted cautiously: its strongest architectural claims—particularly about multi-tenant SaaS—show correlation rather than causation and come from an identity vendor, so stakeholders should independently validate them while adopting the report’s sensible call for much stronger runtime AI-access controls.

FusionAuth’s 2026 State of AI and Identity Report: How AI Adoption is Reshaping Identity Infrastructure, Security Posture, and Enterprise Trust is a timely, commercially sponsored survey of more than 300 technology, security, product and infrastructure leaders. Its central argument is that enterprise AI has crossed from experimentation into operational use while identity-and-access infrastructure has not evolved quickly enough to govern AI agents, machine identities and AI-assisted workflows. The report says 65% of respondents experienced a confirmed AI identity-related security incident during the previous 12 months, 80% report “shadow AI”, 88% believe AI deployment is ahead of identity/security infrastructure, and 93% say AI is already causing or contributing to an identity-infrastructure rethink.

My overall assessment is that the report is directionally important but empirically less conclusive than its strongest language suggests. Its most valuable insight is not any individual percentage. It is the conceptual shift from treating identity as a human-login problem to treating every human, workload, service and AI agent as a separately governed actor whose authority must be scoped, observable and revocable. That direction is strongly consistent with zero-trust guidance from NIST, OAuth security standards and emerging IETF work specifically on AI-agent authentication. NIST’s cloud-native zero-trust architecture expressly centres application and service identities and granular policy enforcement irrespective of whether workloads run on-premises or across clouds; the IETF’s 2026 AI-agent work similarly builds on workload identity and OAuth rather than assuming traditional user authentication is enough.

The report is also persuasive when it argues that policy maturity is not equivalent to runtime protection. Its surveyed organisations frequently report policies and formal lifecycle processes while simultaneously reporting incidents. Recent security research provides an independent reason to take that distinction seriously: indirect prompt-injection attacks have bypassed multiple proposed agent defences, while 2025–26 research shows that action-level controls and step-level intervention can materially reduce unsafe tool use. Identity therefore provides an essential authority boundary, but it is not a complete AI-safety architecture.

The report’s weakest major conclusion is that multi-tenant SaaS identity is itself a “first-order security variable” and substantially less safe than self-hosting. The reported association is striking—on one comparison, 83% of multi-tenant SaaS respondents report confirmed incidents versus 38% of self-hosted/on-premises respondents—but the study does not demonstrate causality. It gives no subgroup sample sizes, confidence intervals, statistical tests or adjustment for AI adoption intensity, organisation size, sector, detection capability or number of integrations. Indeed, the report itself shows that the SaaS cohort is simultaneously more AI-saturated, more confident, more heavily invested and more exposed to shadow AI. NIST guidance is a useful corrective: secure identity policies can be enforced at the application/service level irrespective of workload location. Properly scoped OAuth tokens should also be restricted by privilege and audience, meaning a compromised credential need not automatically grant access across every connected workflow. Architecture certainly matters; hosting model alone has not been shown here to cause the outcome.

There are meaningful methodological limitations. The report says only that it surveyed “over 300 qualified respondents”; it does not disclose the exact sample size, fieldwork dates, survey-recruitment method, sampling frame, response rate, questionnaire, weighting, subgroup sizes or definitions of consequential terms such as “confirmed incident”, “near miss”, “shadow AI” and “comprehensive policy”. It also contains several apparent editorial/data inconsistencies discussed below. Its exact publication date and named individual authors are unspecified; FusionAuth is clearly the publisher/sponsor, and the report closes with a FusionAuth commercial call to action. These facts do not invalidate the research, but they make it better treated as vendor-sponsored directional market intelligence rather than a population-level epidemiology of AI security incidents.

For AI users, the report’s message is consequential. An AI system connected to email, databases, cloud resources, payment systems or customer information should not simply inherit a user’s standing privileges. It should operate through explicit delegated authority, short-lived and narrowly scoped credentials, deterministic policy enforcement before retrieval or execution, and an audit trail that distinguishes the human principal from the AI actor. OAuth Token Exchange already defines useful distinctions between a subject and an acting party, while current IETF AI-agent work is trying to apply these established identity concepts systematically to agentic systems.

For regulators and policymakers, the report should not be interpreted as evidence for mandating self-hosting. Outcome-oriented requirements—least privilege, traceability, isolation appropriate to risk, revocation, security testing, privacy by design and demonstrable control of delegated access—are more defensible. As of August 2026, the EU AI Act’s Article 50 transparency obligations apply, and enforcement powers for several AI Act provisions have commenced; meanwhile UK data-protection law already requires data protection by design and default, including limiting accessibility of personal information to what is necessary. There is, however, no generic AI Act rule requiring every AI application to use single-tenant infrastructure.

The practical conclusion is therefore somewhat broader than FusionAuth’s slogan that “AI can assist. Identity decides”. A better formulation would be: identity determines what an AI actor is permitted to do; safety controls determine whether a permitted action should actually be executed; privacy rules determine what data should be accessible at all; and observability determines whether organisations can reconstruct and contain failures. Secure agentic AI requires all four.

The report asks a simple question: companies are giving AI systems more things to do, but have they built equivalent controls around who—or what—those systems are allowed to act as? FusionAuth’s answer is largely “not yet”.

An ordinary identity system historically concentrates on people: Alice logs in, proves who she is and receives permissions associated with her account. Modern enterprise software already complicated this model through APIs, service accounts, automated jobs and machine credentials. Agentic AI adds another layer. An agent might operate because Alice asked it to do something, but the agent itself may call several tools, retrieve data, invoke APIs and trigger follow-on agents. The important identity questions therefore become: who initiated the action, which software agent actually performed it, which authority was delegated to that agent, what data it could retrieve, which downstream systems accepted its credential, and how quickly that authority can be withdrawn. That conceptual shift underpins the report. It also resembles the delegation model already formalised in OAuth Token Exchange, where a token can preserve both a subject and a distinct actor acting on the subject’s behalf.

The report’s first substantive claim is that its sample has crossed an “AI saturation threshold”. Page 6 reports that 67% have approved AI tools widespread across most departments, roughly 80% have AI-powered product features live in production, 93% have such features in production or pilot, and 86% of respondents personally use AI tools in their daily work. That describes an unusually AI-intensive sample. For comparison, Stanford’s 2026 AI Index reports AI use somewhere in the organisation among 88% of its surveyed organisations and generative AI in at least one business function among 70%, yet AI-agent deployment remained in the single digits in nearly all business functions. OECD statistics use a broader population and definition and found that 20.2% of firms in participating countries used AI in 2025, rising to 52% among large firms. These comparisons are not contradictions; they demonstrate why sample frame and the definition of “AI use” matter enormously.

The report then makes the striking observation that risk indicators increase as AI becomes more pervasive. Among organisations piloting AI only in selected teams, 9% report a confirmed incident, versus 61% where adoption is common in engineering/IT and 74% where AI is widespread across most departments. Shadow-AI reports rise from 27% to 68% to 88% over the same three categories. The obvious interpretation is plausible: more AI integrations create more exposure. But there is another mechanism as well—organisations doing more AI have more opportunities to observe and classify an AI-related incident. Exposure and detection are therefore intertwined.

The most useful charts can be condensed as follows:

Pages 11–15 introduce what the report calls the “confidence-reality gap”: the most confident respondents report the most incidents. The underlying idea is more sophisticated than the headline might imply. The report explicitly says confidence does not cause incidents and offers two plausible explanations: high-confidence companies may be moving fastest and therefore have more exposure, while mature security organisations may simply detect events that less mature organisations miss. That acknowledgement is one of the report’s strongest analytical passages because it recognises a classic observational-data problem rather than claiming a paradoxical causal effect.

Pages 16–18 then compare policies with operational controls. Seventy-three per cent say they have comprehensive policies governing AI-agent authentication, permissions and revocation. Formalisation is highest for provisioning identities (83%), anomalous-behaviour monitoring (81%) and permission scoping (79%), falling to 77% for credential rotation/expiry, 73% for revocation and 70% for auditing. The plain-language point is compelling: enterprises are better at giving an agent an identity than at proving precisely what it subsequently did or terminating its authority promptly.

The report’s final technical checklist is accordingly sensible. It asks organisations to evaluate first-class machine identity, fine-grained authorisation, tenant separation, deterministic runtime policy, complete auditability, credential expiry/revocation, real-time authorisation, authorisation-aware retrieval and detection of shadow AI. Most of these controls are not proprietary concepts. OAuth security best practice already says access tokens should receive only the minimum required privilege and should be audience-restricted; NIST’s zero-trust guidance calls for granular application- and service-identity policies; and the emerging IETF AI-agent authentication work explicitly proposes applying OAuth and workload-identity standards to agents.

The conceptual architecture implied by the report—and, with some additions, supported by the wider evidence—looks like this:

This is a synthesis rather than a diagram from FusionAuth. The critical additions are the separation of human principal from agent actor, policy checks outside the probabilistic model, and an independent control at the point of tool execution. Those elements are supported by OAuth’s subject/actor delegation model, NIST’s identity-centred zero-trust approach and recent agent-security research on runtime tool-call guards.

The report’s research design is adequate for detecting patterns worth investigating, but not for establishing population prevalence or causal relationships. FusionAuth says respondents were qualified and screened for relevance to AI, identity and security decision-making, which improves topical relevance. The sample also intentionally covers multiple senior roles, company sizes, industries and geographical cuts. For a commercial market survey, these are useful characteristics.

The disclosure standard, however, is substantially below what would be expected for research intended to support strong inferential conclusions. The report does not reveal the exact number of respondents beyond “over 300”; fieldwork dates; survey panel/provider; recruitment mechanism; sampling frame; invitations versus completed surveys; response rate; quotas; respondent distribution; weights; full questionnaire; handling of missing data; or the number of observations underlying almost every subgroup. Because many charts break the already modest sample into architecture, role, revenue, industry or region, subgroup uncertainty could be considerable. The report acknowledges this only once explicitly, by marking the $1 billion-plus revenue segment as a small sample to be interpreted directionally.

The absence of operational definitions is especially important. A “confirmed AI identity-related security incident” might mean compromised credentials with data loss, an improperly permissioned agent caught before exploitation, policy violation, cross-tenant access, or something else. “Near miss”, “shadow AI”, “well prepared”, “comprehensive policy” and “formalised process” similarly rely on respondent interpretation. Page 10 even switches rhetorically from the survey’s “confirmed incident” measure to saying 86% of one cohort has been “breached”. Those are not automatically equivalent concepts; precise security research should not collapse them without a definition.

Self-reporting creates several sources of bias. Security leaders with sophisticated detection systems are more capable of recognising incidents. Organisations with extensive AI deployment have more events capable of qualifying as AI-related. Security executives may classify events differently from engineering leaders—the report itself observes that CISOs report more confirmed incidents while platform leaders report more near misses. Consequently, a higher reported incident rate can represent some mixture of greater underlying risk, greater exposure, better detection, different taxonomies and role-dependent reporting. The report correctly acknowledges part of this problem in its confidence discussion, but does not statistically separate these mechanisms.

The same limitation is decisive for its architecture thesis. Page 19 reports, among other differences, SaaS multi-tenant versus self-hosted/on-prem figures of 83% versus 38% for confirmed incidents, 91% versus 56% for shadow AI and 84% versus 26% for significant investment. Yet the SaaS cohort also reports much greater belief that AI is outpacing infrastructure—83% versus 26%—and much greater formal policy maturity and confidence. Those covariates make it impossible to tell from the published tables whether SaaS multi-tenancy itself explains the incident difference or whether the SaaS group simply represents faster-moving, more integrated, more observable organisations.

Technically, the report’s statement that in a shared SaaS identity environment “a single compromised token or misconfigured policy” can cascade across every connected AI workflow should also be read as a risk scenario, not an intrinsic property of multi-tenancy. OAuth’s current security Best Current Practice says privileges should be restricted to the minimum required and tokens should be audience-restricted to particular resource servers precisely to contain token leakage. NIST SP 800-207A likewise describes granular application/service-identity controls that operate independently of whether workloads are on-premises, hybrid or multi-cloud. A badly designed self-hosted deployment can therefore be dangerous, while a strongly isolated multi-tenant system can be robust. Deployment architecture is indeed a security variable; “SaaS versus self-hosted” is too coarse to serve as the variable by itself.

There are also several apparent internal quality-control errors:

The external contextual sourcing deserves a similarly mixed judgement. The report’s claim that non-human identities can vastly outnumber human identities is supported by Entro’s vendor telemetry: its H1 2025 analysis covered more than 27 million NHIs and reported a 144:1 NHI-to-human ratio; its earlier research reported 97% of NHIs with excessive privileges. These are useful real-world telemetry data, but Entro’s customer base is not necessarily representative of the average global enterprise, and Entro itself sells NHI-security products.

Likewise, the report’s Palo Alto Networks reference is substantially grounded but somewhat overgeneralised. Unit 42’s 2026 report analysed more than 750 major incident-response engagements from 2025 and found identity involved in 89% of its investigations. The careful formulation is therefore “89% of Unit 42’s investigated incidents”, not that identity drives 90% of all global security incidents.

The report also cites a projection that the IAM market will reach roughly $42.6 billion by 2030 at a 10.4% CAGR. That matches MarketsandMarkets’ commercial forecast of $25.96 billion in 2025 rising to $42.61 billion in 2030. Such market-sizing estimates should be treated as forecasts rather than measurements of an underlying natural quantity. Similarly, the Forrester statement that enterprises could push 25% of planned AI spending into 2027 is accurately traced to Forrester’s prediction, not an observed 2026 spending outcome.

None of these limitations destroys the report’s value. They change the appropriate epistemic status: the survey is good at generating hypotheses and highlighting practitioner concerns; it is weak as proof of causal security effects or exact industry-wide incidence rates.

Privacy. The report is most immediately relevant when agents can retrieve customer, employee or other personal information. A traditional chatbot that only generates text from public knowledge has one risk profile; an agent connected to email, CRM, HR records or production databases has another because an erroneous or malicious instruction can become a data-access event. The report’s recommendation for authorisation-aware retrieval is therefore important: the permission check should happen before material is retrieved and inserted into the model context, rather than asking the model itself to decide whether the user ought to see it. UK ICO guidance similarly requires organisations to consider privacy from system design onwards, use only personal information necessary for a specified purpose, limit accessibility and maintain audit trails around AI processing.

This changes what privacy means for an AI user. Giving an AI assistant permission to “help with email” should not silently become indefinite access to every mailbox, attachment and connected application. Authority should be purpose-bound, inspectable and easy to withdraw. The human should also be distinguishable from the agent in downstream logs. OAuth Token Exchange is useful conceptually because delegation preserves the distinction between the subject whose rights are being exercised and the actor exercising them.

Safety. FusionAuth is right that deterministic identity controls should sit outside the probabilistic model. A language model should not be the final authority on whether it is allowed to transfer money, delete data, change an account permission or expose a confidential document. But identity cannot answer a different question: has an authorised agent been manipulated into taking an unsafe action? Recent peer-reviewed research demonstrates why that distinction matters. A 2025 NAACL study adaptively bypassed eight indirect-prompt-injection defences and achieved attack success above 50% across those evaluated defences. A 2026 ACL paper, conversely, found that step-level monitoring and intervention reduced harmful tool invocations by an average of about 65% in its benchmark.

The correct safety model is consequently defence in depth: constrain what the agent cando through identity and authorisation; assess whether the specific proposed action is consistent with the user’s task; isolate untrusted content from privileged instructions; require stronger confirmation for consequential or irreversible actions; monitor behaviour; and terminate authority quickly after anomalies. NIST’s Generative AI Profile similarly frames GenAI risk management as a lifecycle-wide exercise rather than a single-control problem.

Usability. Stronger authorisation can make AI either safer or frustrating. Asking a user to approve every low-risk retrieval would destroy much of the value of an assistant; giving permanent blanket access in order to avoid those prompts creates excessive authority. The engineering objective should therefore be low-friction least privilege: narrowly scoped delegated tokens, contextual permissions, automated expiry, step-up confirmation only where risk warrants it, and sufficiently fast policy engines that security does not become a bottleneck. The report correctly identifies real-time authorisation performance as an architectural consideration, while OAuth security guidance supports minimising token privileges and audience.

Trust and accountability. Users will increasingly need more than a statement that an AI system is “secure”. They need traceability: which account authorised the action; which agent performed it; which model/tool chain was involved; what data was accessed; which policy permitted it; and what happened next? The report’s focus on auditability is therefore more important than some of its headline incident percentages. OAuth’s actor-chain mechanism already provides a technical vocabulary for retaining delegation history, while ICO guidance recommends audit trails that record access, modification and processing of personal information.

Regulation. The report is right that identity architecture can become part of regulatory and customer assurance, but the legal claim needs precision. As of 2 August 2026, the EU AI Act is broadly applicable subject to its staged exceptions; Article 50 transparency obligations now require, among other things, certain direct AI interactions to be disclosed and certain synthetic content to be identifiable. Enforcement powers for applicable provisions also commenced on 2 August 2026, while the amended timeline places Annex III high-risk-system requirements from 2 December 2027 and high-risk systems embedded in regulated products from 2 August 2028.

Those AI Act rules should not be conflated with a universal requirement for tenant isolation. For organisations processing personal information, more direct obligations arise from data-protection principles such as security, data minimisation, accountability and data protection by design/default. The ICO’s guidance, updated following the UK’s Data (Use and Access) Act 2025, says organisations should by default use only the personal information necessary for their purpose and restrict accessibility accordingly. Whether that calls for logical multi-tenant isolation, dedicated infrastructure or self-hosting depends on the actual risk and implementation, not a categorical legal rule.

Business impact. The report says 85% of respondents have faced tenant-isolation demands at least occasionally, 93% regard AI as a driver of identity reevaluation and 91% expect moderate or significant identity-investment increases. It also reports that support for machine/non-human identity (72%), deployment flexibility (57%) and fine-grained authorisation (54%) outrank cost (11%) among its selected identity-buying criteria. Those findings suggest that enterprise buyers increasingly view identity architecture as part of product assurance rather than merely back-office IT.

That does not mean businesses should embark on expensive self-hosting migrations simply because of the report. The external economic environment argues for a stricter evidence standard: Forrester’s 2026 prediction anticipated enterprises deferring a quarter of planned AI spending into 2027 amid greater scrutiny of measurable ROI, even while its broader technology forecast expects overall technology spending to continue growing. Identity investment should therefore be justified through measurable outcomes—reduced privilege, shorter credential lifetimes, faster revocation, lower cross-tenant leakage probability, fewer unauthorised tool actions and improved mean time to detect/contain—not through a vague claim of being “AI ready”.

The wider security evidence nevertheless supports taking machine identity seriously. Unit 42 found identity involved in 89% of its more than 750 major 2025 incident-response engagements, while Entro’s vendor telemetry documents extreme growth and over-privilege in non-human identities. Neither source proves that AI is responsible for most identity attacks, but together they show that autonomous AI is being introduced into an enterprise environment where excessive machine authority was already a serious security problem.

The distinction between evidence strength and confidence is important here. Evidence strength asks how rigorous the supporting research design is. Confidence asks how strongly the stated conclusion is justified after combining the report with independent evidence.

The most important distinction in the table is between architectural principle and vendor-specific architectural conclusion. The evidence strongly supports first-class agent identity, least privilege, isolation, deterministic authorisation, credential lifecycle management and logging. It does not establish that a particular hosting model is intrinsically safer. An organisation deciding between SaaS, dedicated cloud, hybrid and self-hosted identity should test actual isolation guarantees, token semantics, control-plane compromise scenarios, operational competence, disaster recovery, observability and revocation—not use the deployment label as a proxy for all of them.

The SWOT reveals an important paradox of its own: the report is strongest as an argument against security theatre, yet some of its architecture claims could themselves encourage a new form of security theatre if readers substitute “self-hosted” for measurable protection. The right lesson is not “buy architecture X”; it is “make authority explicit and prove through tests and telemetry that the chosen architecture contains failure”.

The recommendations below preserve the report’s strongest insight—AI needs a new identity/control layer—while correcting for its methodological and technical overreach.

For boards and senior management, this implies replacing generic “AI readiness” dashboards with outcome-oriented measures. Instead of reporting that 100% of teams have an AI policy, ask what proportion of agents have named human owners, what proportion use unique identities, the median credential lifetime, how many permissions exceed observed need, how quickly agent authority can be revoked, whether cross-tenant access tests fail safely, what percentage of sensitive tool actions require independent authorisation, how many shadow integrations were discovered, and how reliably an incident can be reconstructed afterwards. This directly addresses the report’s valuable distinction between governance activity and security outcomes.

It is equally important not to turn near misses into a simplistic performance metric. A higher near-miss rate can mean excellent detection and containment, or it can mean an organisation is repeatedly entering dangerous states. A falling confirmed-incident rate can mean stronger prevention, or weaker detection. Future assessments should therefore use denominators such as agent actions or privileged tool calls and pair them with severity, detection latency and prevented-impact measures. That analytical discipline is missing from the current survey but follows directly from the detection-bias problem that FusionAuth itself recognises.

For privacy, the strategic goal should be minimum necessary authority, not merely strong authentication. The fact that an AI system can prove its identity does not justify its access to a particular customer record. ICO guidance makes this distinction important under UK data-protection principles: organisations must design systems so that personal information and its accessibility are limited to what is necessary for the stated purpose, while auditability and monitoring help demonstrate accountability. In an agentic system, privacy engineering and identity engineering increasingly meet at the authorisation boundary.

For safety, the comparable principle is minimum necessary agency. An agent that needs to summarise a purchase order does not automatically need authority to approve payment; an assistant that drafts an email does not necessarily need permission to send it; and an agent that searches a knowledge base need not receive access to every repository available to its human owner. This is both a least-privilege principle and a defence against prompt-injection escalation. Research showing that indirect prompt injections can defeat model-level defences, alongside work showing benefits from action-level tool guards, makes separating language-model reasoning from execution authority particularly important.

For trust, the target state is attributable delegation. Every consequential AI action should make it possible to answer: Who authorised this agent? What exact authority was delegated? Which actor used it? Which resource accepted it? What information influenced the action? What policy allowed execution? When did the authority expire? OAuth’s distinction between subject and actor demonstrates that much of the identity vocabulary required for such systems already exists; the task now is to apply and extend it consistently to AI agents.

Finally, the report’s architecture conclusion should be reframed. The future of AI identity probably will be architecture-led, but not in the narrow sense of SaaS versus self-hosted. The security-relevant architecture is the complete authority path: identity issuance, delegation, credential scope and lifetime, policy decision point, tenant and data isolation, retrieval controls, execution gateway, human escalation, telemetry and revocation. NIST explicitly treats identity-based policies as capable of operating across on-premises and multiple-cloud environments, reinforcing the principle that strong control does not depend on a single hosting topology.

FusionAuth’s report is therefore best read as an early-warning signal and architectural agenda, rather than conclusive comparative evidence about deployment models. Its survey indicates that highly AI-active enterprises are experiencing substantial identity-management pressure, and external evidence independently confirms that machine identities, excessive privileges and identity-driven attacks deserve serious attention. The report is particularly valuable in insisting that written governance is no substitute for enforceable controls and that AI agents need lifecycle management extending through auditing and revocation.

Its most important recommendation should nevertheless be widened. AI can reason; identity constrains authority; policy authorises; safety controls inspect actions; privacy limits data exposure; humans remain accountable; and telemetry proves what actually happened. Organisations that build all of these layers will be much better positioned than those that merely declare themselves “AI ready”—regardless of whether their identity platform is multi-tenant SaaS, dedicated cloud or self-hosted.

• Palo Alto Networks Unit 42 — 2026 Global Incident Response Report.
  This supports the broader point that identity has become a central attack surface. Unit 42 reports that identity weaknesses played a material role in 89%—approximately 90%—of its investigations, based on more than 750 major incidents handled during 2025.
  Unit 42 – 2026 Global Incident Response Report

• Forrester — 2026 Technology & Security Predictions, 28 October 2025.
  Source for the report’s statement that enterprises could defer 25% of planned AI spending into 2027 as organizations demand clearer ROI from AI investments.
  Forrester – 2026 Technology & Security Predictions

• Entro Security — NHI & Secrets Risk Report H1 2025.
  This is the underlying source identified by FusionAuth for the striking 144 non-human identities for every human identity statistic. FusionAuth’s own follow-up article explicitly attributes the 144:1 figure to Entro Labs’ H1 2025 research; Entro also reports very high levels of excessive privilege among NHIs.
  Entro Security – NHI & Secrets Risk Report H1 2025

• Non-Human Identity Management Group — NHI Research and Knowledge Centre.
  The FusionAuth report identifies the Non-Human Identity Management Group when discussing the rapid proliferation and governance problems of machine and other non-human identities. The group’s materials also catalogue research from Entro, SailPoint, GitGuardian, Akeyless and others.
  Non-Human Identity Management Group

• MarketsandMarkets — Identity and Access Management (IAM) Market – Global Forecast to 2030.
  This verifies the market-size number quoted in the FusionAuth report: the global IAM market is projected to grow from $25.96 billion in 2025 to $42.61 billion in 2030, a CAGR of 10.4%.
  MarketsandMarkets – IAM Market Report