The theme for
Identiverse 2026 was
“The Global Imperative – The Foundation of Trust.” That could have been just another conference theme. It wasn’t. It worked because it captured where the identity industry is right now: under pressure, in motion, and being asked to solve problems that are no longer neatly contained inside IAM.
Identity used to be easier to box in. It was the login page. The directory. The access request. The thing security cared about, IT operated, and everyone else complained about when it got in the way.
That version of identity is not entirely gone, but it’s such a small part of what we as cybersecurity and identity practitioners see every day.
Today, identity sits in the middle of security, fraud prevention, privacy, customer experience, workforce operations, regulatory accountability, and AI governance. It determines who gets access, what they can do, what systems can do on their behalf, and how an organization explains what happened when something goes wrong.
That is a lot of responsibility for a discipline that many organizations still treat as a one-time tool purchase, and we discussed all of it at Identiverse this year.
Identity is not just authentication
The first pain point is old, familiar, and apparently still necessary to say: identity is not the same thing as authentication.
Authentication matters. Strong authentication matters. Phishing-resistant authentication matters a great deal.
But authentication is only one part of the identity story. Modern identity programs also depend on proofing, authorization, recovery, lifecycle management, governance, monitoring, and audit. Each of those answers a different question.
Who is this person or entity? Are they still the same actor we enrolled earlier? What are they allowed to do? What happens when they lose access? What happens when access has to be delegated? What happens when access must be revoked? Who can explain the decision later?
Organizations get into trouble when they collapse all of that complexity into “can the user log in?”
A good login flow does not fix a bad recovery process. A modern identity provider does not fix poor data quality. A clean role model does not survive long if nobody owns exceptions, policy drift, or lifecycle changes.
Identity starts simple, usually because people are looking at the wrong part of the system.
AI agents make delegation impossible to ignore
Non-human identities are not new. Identity teams have been dealing with service accounts, workloads, scripts, batch jobs, and integration pipelines for years. But several sessions pointed out that AI agents are different enough to make the old assumptions around NHI wobble.
Traditional automation usually follows a path someone designed in advance. An AI agent may interpret intent, select tools, call APIs, chain actions together, and operate across systems on behalf of a user. That does not make it magic. It does make it harder to govern.
The awkward part is that agentic AI collapses several questions that identity systems have historically handled separately. Is this a user action? A machine action? A delegated action? A system-generated recommendation? A transaction carried out under standing authority? Something else entirely?
Those distinctions matter. Without them, organizations end up with activity they can technically authenticate but cannot adequately explain.
That is where a lot of current implementations look fragile. API keys and broad, persistent credentials may be easy to issue, but they are a poor fit for delegated, task-specific activity. They answer the easy technical question — can this system connect? — while avoiding the harder governance question: what authority is this system exercising, and where did that authority come from?
Agentic systems need clearer models for delegated, time-bound, task-scoped authority. They need attribution. They need revocation. They need audit trails that a human can understand after the fact.
Without that, organizations are not building trustworthy AI-enabled workflows. They are creating new places for authority to leak.
Authorization is where the next mess lives
AI agents make delegation urgent, but they are not the only reason authorization is under pressure.
The identity industry has spent years improving authentication. That work is not finished, but it is no longer the only hard part. Once someone — or something — has authenticated, the harder question is what they should be allowed to do next.
This is where many existing access models start to creak.
Static roles, fixed trust relationships, and one-time access decisions struggle in environments where people move across devices, services call other services, business relationships cross organizational boundaries, and risk changes during the life of a session. Add agents to that mix and the problem gets sharper, but the underlying issue was already there.
Authorization is becoming more contextual. Decisions increasingly depend on who is acting, what they are trying to do, what resource is involved, what signals are available, what relationship exists, what risk is present, and whether the action still fits the original purpose.
That is why continuous authorization, policy-based access control, relationship-based models, and richer context are getting more attention. They are attempts to deal with a real problem: access decisions are no longer clean, stable, or limited to a single moment in time.
But this is not a free upgrade.
A policy system that nobody understands is not advanced. It is dangerous. A rule set full of exceptions is not flexible. It is probably waiting to break. A continuous authorization model without clear ownership, testing, and observability is not a strategy. It is a future incident report with better branding.
Identity architects need authorization systems that can adapt without becoming unreadable. That may be one of the hardest balances in the next phase of identity work.
Trust decisions need better signals, not just more signals
AI also makes authenticity harder.
A system may be dealing with a human user, a normal automated process, an AI agent acting for a person, or a malicious actor generating synthetic activity at scale. Some of those interactions will use legitimate interfaces. Some may use valid credentials. Some may look normal until the damage is done.
That pushes identity systems toward more signals: device posture, behavioral patterns, transaction context, provenance, content authenticity, risk scoring, and other indicators that help establish whether an interaction deserves trust.
That shift is necessary. It is also easy to get wrong.
More signals do not automatically produce better decisions. They can just as easily produce opaque decisions, privacy concerns, brittle controls, and false confidence. A system that consumes a dozen signals but cannot explain which ones mattered is not necessarily more mature. It may simply be harder to challenge.
For security practitioners, the issue is not whether signals are useful. They are. The issue is whether they are reliable, explainable, and tied to decisions the organization is prepared to defend.
For identity architects, the challenge is designing systems that can use context without becoming impossible to reason about.
Standards help. They do not save you.
Standards matter. They make interoperability possible. They give implementers shared tools and shared language. They help ecosystems scale beyond bespoke integrations and private agreements.
But standards do not make trust decisions for you.
Two organizations can implement the same protocol and still make very different choices about risk, privacy, delegation, retention, liability, and operational control. That is not a standards failure. It is a reminder that mechanisms and governance are not the same thing.
This distinction matters as identity work moves deeper into agents, verifiable credentials, continuous signals, delegated authorization, and cross-ecosystem trust. The technical questions are hard. The meaning questions may be harder.
What does delegation mean when software acts for a person? What does consent mean when actions are automated and chained? What does accountability mean when authority crosses systems and organizations?
Those questions cannot be solved by implementation alone.
The foundation has to hold under stress
The larger message from Identiverse 2026 is that identity is conclusively part of the foundation layer for digital trust.
That foundation has to support people, machines, agents, organizations, regulators, auditors, and attackers who are paying attention. It has to support normal operations and failure conditions. It has to support innovation without losing accountability.
That is where the “foundation of trust” language becomes more than a theme.
For security practitioners, identity belongs in threat modeling, resilience planning, fraud strategy, incident response, and AI governance. It is not just an access control concern.
For identity architects, the job is to make authority visible, constrained, auditable, and revocable. Not in the abstract. In production. Under stress. When the edge cases show up.
The work ahead is not simply about letting the right users in.
It is about understanding who or what is acting, under whose authority, with what limits, and how much trust that action deserves.
That is the global imperative. Not because it sounds grand, but because the alternative is building systems no one can fully explain when they matter most.
