I just got back from about ten days of vacation between New York and Connecticut. It was my first time in Manhattan and I fell in love with it! Anyone who has visited knows its unique “organized chaos”: a constant flow of people, lights, ideas, and opportunities. Roaming the city, one thing especially caught my eye: Artificial Intelligence is everywhere, visible and explicit.

Not in keynotes or demos for insiders.

In everyday life.

AI has become part of the city’s urban and cultural landscape.

AI Among the Giants of Times Square

#

Walking through Times Square, the world’s most iconic advertising plaza, alongside historic brands like Coca Cola, Samsung, and M&M’S, I saw an ad for Arize AI.

Arize is a California startup founded in 2020 that develops observability and monitoring platforms for AI models and LLM systems in production. We’re not talking about a social network, a consumer app, or a new tech gadget, but a deeply technical B2B product aimed at the enterprise world.

And that’s exactly the point.

It wasn’t just advertising. It was a symbolic change of status.

AI companies born just a few years ago are now occupying the same cultural and media spaces that for decades were reserved for global consumer brands.

It’s perhaps the clearest sign that AI has now left the tech niche to become mainstream.

Not only that: Anthropic, OpenAI, and other SaaS AI platforms were featured in ads and banners, both outdoors and in the subways. AI is no longer just a topic for insiders: it’s an integral part of New York’s urban and cultural fabric.

AI in Cafés and the Normality of Prompting

#

In cafés—from Starbucks to Dunkin’, Blank Street to Gregorys—watching open laptops, I noticed a constant. Whether students, designers, journalists, or developers, everyone—sooner or later—interacted with an AI tool: Copilot in VSCode, Claude Code, ChatGPT, Gemini. It wasn’t the exception; it was the rule. AI has become the silent companion of those who work, study, and create.

The most interesting thing wasn’t seeing someone use ChatGPT. It was seeing how normal it all seemed.

No one was “trying out AI.”

AI was already integrated into the way people work, study, and code.

A Cultural Gap

#

On the subway, watching a guy iterate on a prompt in Claude, I remembered a conversation before I left. A colleague, just back from a week of training in the US, told me: “They’re at least six months ahead here. AI is already part of daily work life; in Europe, we’ll get there, but more slowly.”

My colleague’s impression is confirmed by the data, though the picture is more nuanced. While the US leads in infrastructure and frontier model development, it ranks only 24th globally for AI usage among the population (28.3%), surpassed by the UAE, Singapore, and Nordic European countries like Norway, Ireland, and France.¹

The real gap emerges when looking at professional adoption: 41% of American workers use GenAI tools for professional activities,² compared to about ~20% of EU companies—with an even greater gap between large enterprises (55%) and SMEs (17%).³

The difference isn’t so much in knowing how to use AI, but in the speed with which it’s incorporated into organizations’ daily processes.

This speed, in turn, is influenced by two deeply intertwined factors.

The first is cultural: in the US, adoption is often driven by a rapid experimentation mindset—a “try first, govern later” approach that accelerates spread but leaves many risks open. In Europe, companies and workers tend to have greater sensitivity to privacy, accountability, and risk management.

The second is regulatory: frameworks like the EU AI Act arise from this cultural context—not just as constraints, but as a response to a stronger demand for transparency and human oversight. In the short term, this slows down more spontaneous adoption. In the long run, however, it could become an advantage for organizations able to integrate AI, governance, and security sustainably from the start.

Chaotic Growth, Real Risks

#

AI usage is growing at a dizzying pace, but often in a disorganized way. In many companies, adoption starts from small teams or individuals—what we call Shadow AI: AI tools adopted without IT supervision, without governance, often with access to sensitive data that no one has formally authorized.

CISOs struggle to map how many and which AI tools are actually in use, what data they access, and with what permissions. In the name of speed, developers are increasingly granting AI agents tokens, API keys, and credentials with extended—sometimes even global—privileges, without the same level of control they’d apply to a human or traditional service.

I analyzed this risk in detail in the article “Securing AI: Okta’s Blueprint for the Secure Agentic Enterprise”, but the key point is simple: the speed of adoption is real—and so are the risks it brings.

In New York, I also walked past the historic Ghostbusters firehouse. And in the end, Shadow AI is a lot like a ghost: invisible until it causes damage, hard to track, and often already inside the organization before anyone notices.

Who you gonna call? In the movie, you just called the Ghostbusters. In the enterprise world, unfortunately, you need something more.

The Role of Governance and Compliance

#

In Europe, the situation is made more complex (and, in part, safer) by regulations like the EU AI Act, NIS2, and DORA. If these rules sometimes seem excessive, they’re designed to protect citizens and workers, and are often an antidote to uncontrolled chaos. The AI Act, in particular, imposes requirements for traceability, human oversight, responsibility, and transparency that force companies to treat AI agents as first-class identities.

Checklist: How to Prepare for AI Governance

#

• Map all AI tools in use (official and shadow) → Okta Universal Directory and ISPM can help discover and classify them.
• Define clear policies on who can use what and with which data → The various O4AA access patterns offer concrete models for managing permissions and scopes. In particular, XAA (Cross App Access) is designed for AI agents that need to interact with multiple systems.
• Implement access and audit controls for AI agents → Okta policies, logs, and Governance features (like Access Requests and Certification Campaigns) can help monitor and govern AI agents like any other critical identity.
• Train teams on AI risks, limits, and responsibilities.
• Constantly monitor costs and optimize token usage.
• Regularly update policies based on regulatory and technological changes.

Beyond the specific platforms or vendors chosen, the fundamental point is to start treating AI agents as real operational identities, with access, permissions, audit, and lifecycle to be governed like any other critical entity in the organization.

Platforms like Okta can help build this level of control and governance, but the challenge is first and foremost architectural and cultural: avoiding a situation where speed of adoption and control run on separate tracks.

Toward the Agentic Enterprise: The Maturity Challenge

#

The real challenge isn’t adopting AI—that battle is already won, as the data and what I saw in New York show. The challenge is to do it safely, with governance, and sustainably over time.

For years, we’ve treated software tools as simple applications. AI agents completely change the paradigm: they make decisions, execute workflows, access systems, and interact with sensitive data.

Concretely, this means knowing which AI agents operate in your organization, with which identities, what permissions, and access to which data. It means treating every AI agent as a first-class identity—not just a tool, but an actor with credentials, scope, and lifecycle to manage. This is where identity management returns to center stage.

The O4AA (Okta for AI Agents) framework and the Blueprint were created precisely for this need: to offer concrete access patterns for those building or governing agentic systems.

Conclusions: AI Is Here to Stay. Are You Ready?

#

AI is no longer a promise: it’s daily reality, visible in the world’s innovation hotspots. But its adoption brings new risks, requiring governance, awareness, and the right tools. In Europe, the path is slower but—perhaps—safer.

In New York, I had the very concrete feeling that AI has already passed the cultural point of no return. It’s no longer a “special” tool: it’s becoming the invisible infrastructure of daily work.

The real question now isn’t whether to adopt it. It’s how quickly we’ll be able to govern it before it outpaces the processes, policies, and security models built over the last twenty years.

Let me know your thoughts: have you seen signs of this revolution too? How are you tackling the challenge of AI agent governance? Write in the comments or on LinkedIn!

Introduction

#

A few weeks ago, my friend Matteo Bisi published an excellent post titled "August 2026 Countdown: K8s & AI Compliance" exploring how Kubernetes teams can prepare for EU AI Act enforcement through platform-level automation. Admission controllers, sidecar watermarking, AI-BOMs — the infrastructure angle is real and important.

Reading it, I found myself thinking: infrastructure is necessary, but not sufficient. Every AI agent that runs in a pod, calls an API, or makes a decision on behalf of a user is also an Identity. And identity governance — who the agent is, what it can access, who is accountable for it, and whether its behavior can be traced and overridden — is the compliance dimension that infrastructure tooling alone cannot cover.

That is the perspective I want to bring in this article, the fourth in the O4AA — Okta for AI Agents series:

• In Part 1 we mapped the Agentic Enterprise Blueprint: why AI agents need to be treated as first-class identities, and what shadow AI costs organizations that do not.
• In Part 2 we introduced the four access patterns that govern how agents authenticate to enterprise resources, going deep into each protocol details with Part 3.
• Here, in Part 4, we map the EU AI Act — and its NIST and NIS2/DORA counterparts — article by article to Okta’s capabilities, showing how O4AA turns regulatory requirements into operational controls.

The European Union Artificial Intelligence Act¹, which entered into force in August 2024 and reaches full applicability by August 2026, represents the world’s first broad, horizontal AI regulation. For organizations deploying AI agents, it creates specific compliance obligations that converge directly on identity and access management.

The EU AI Act: A Risk-Based Framework

#

The EU AI Act takes a risk-based approach, categorizing AI systems into four tiers:

1. 🚫 Unacceptable Risk: AI systems that threaten safety, livelihoods, or rights (e.g., social scoring, real-time biometric identification in public spaces) are prohibited
2. ⚠️ High-Risk AI: Systems affecting critical infrastructure, employment, essential services, law enforcement, or democratic processes face strict requirements including:
   • 🔁 Risk management systems
   • 🗄️ Data governance and quality requirements
   • 📄 Technical documentation
   • 🔍 Record-keeping and traceability
   • 👁️ Transparency obligations
   • 🧑‍💼 Human oversight mechanisms
   • 🛡️ Accuracy, robustness, and cybersecurity requirements
3. 💬 Limited Risk: AI systems with transparency obligations (e.g., chatbots must disclose they are AI)
4. ✅ Minimal Risk: AI with no restrictions (e.g., spam filters)

Key Deadlines

#

The regulation’s applicability is phased. Organizations should not treat august 2026 as a distant horizon — several obligations are already in force:

For most enterprise AI agents — those used in HR, customer service, credit scoring, fraud detection, or security monitoring — the critical deadline is August 2, 2027 for systems already deployed, and August 2, 2026 for new deployments. Neither horizon is distant.

Penalty Tiers

#

Non-compliance carries tiered financial penalties based on the severity of the violation:

For SMEs and startups, the percentage cap typically applies.

The regulation imposes fines up to €35 million or 7% of global annual turnover for the most severe violations. The board-level implication is clear: AI identity governance is a financial risk, not just a technical concern¹.

Why AI Agents Trigger Compliance Obligations

#

Enterprise AI agents often fall into high-risk or limited risk categories, triggering substantial compliance obligations. Key requirements directly intersect with identity management:

• Traceability: Organizations must maintain complete audit logs of AI system decisions and actions. Identity governance is a critical enabler — but not the only layer required: application-level logging, SIEM pipelines, and system tracing all contribute alongside it. This is precisely why protocols like XAA/ID-JAG embed a transaction ID in every token alongside agent and user identity, enabling cross-system log correlation.
• Human Oversight: High-risk systems require “human-in-the-loop” or “human-on-the-loop” oversight, demanding mechanisms to pause, override, or revoke agent actions
• Accountability: Organizations must demonstrate who authorized each agent, what data it accessed, and what actions it performed
• Transparency: Users must know when they interact with AI systems, requiring clear agent identification

Examples of enterprise AI agents that trigger obligations:

The Attribution Gap

#

Before diving into the regulatory details, it helps to name the underlying problem precisely. Okta’s own research team calls it the Attribution Gap²: the inability to trace an AI agent’s actions back to an authorized human decision-maker.

When an AI agent approves a loan, generates legal advice, or modifies access permissions, the organization deploying it must be able to answer five questions:

1. Which agent performed the action?
2. What permissions did it have at that moment?
3. Who authorized those permissions, and when?
4. What data did it access?
5. Where is the immutable record of all of the above?

If any of these questions cannot be answered, the organization has an attribution gap — and regulators are not the only ones asking. Courts are already establishing liability regardless of whether a formal compliance framework was violated, as seen in the Air Canada chatbot case³, Italy’s Replika fine⁴, Garcia v. Character Technologies⁵, and Nippon Life v. OpenAI⁶.

The pattern across all four cases is the same: when something goes wrong, regulators and courts ask who was responsible, and organizations without a clear chain of authorization cannot answer. That is the compliance gap Identity Governance must close.

Article-by-Article Compliance Mapping

#

The following sections map each identity-relevant EU AI Act obligation to the O4AA blueprint and the specific Okta capabilities that address it.

Traceability (Article 12)

#

Requirement: Organizations must maintain logs enabling reconstruction of AI system behavior and decisions.

Blueprint reference:

• Audit logs and telemetry — every agent action must produce a tamper-proof record forwarded to a central SIEM.
• Agent lifecycle management — every agent must be a distinct identity with an associated human owner, so logs can attribute actions to authorized humans.
• Agent Integration (MCP Server, SaaS Services, Agent-to-Agent Connections, Service Accounts, Valuted Credentials) — all access patterns must be logged with agent-specific identifiers, never generic service accounts.

Okta Solution:

• Cross-App Access (XAA), thanks to the ID-JAG token, embeds both the authorizing user and the agent identity within the token context — making every action attributable to a specific human-agent pair. It also allows custom risk signals to be injected into the log stream, enriching the traceability data with context like risk scores or external threat intelligence indicators
• Universal Directory ensures that every agent is a distinct identity with mandatory owner attributes, so logs can always attribute actions to a named human sponsor. O4AA agent identity model ensures every log entry is attributed to a named, non-human principal — never a shared account
• Change history tracks every modification to agent policies or credentials
• System Log provides a complete audit trail of agent registration, authentication, access, and deactivation events. Logs capture which resource each agent reached, what action was performed, and the exact timestamp, with a transaction reference that will help correlate with downstream application logs.
• Native integration with SIEM platforms (like Splunk, or Datadog) for long-term retention and cross-system correlation

Human Oversight (Article 14)

#

Requirement: High-risk AI systems must enable human intervention, oversight, or deactivation.

Blueprint reference:

• Human-in-the-loop — approval gates that pause agent operations pending human decision
• Kill switch — immediate, global revocation of agent access
• Agent lifecycle management — human sponsorship and periodic review of every agent ensures ongoing oversight

Okta Solution:

• Universal Logout: single-action revocation terminates all active sessions and tokens for a given agent instantly, satisfying the “ability to deactivate” requirement
• Lifecycle Management (LCM): can deactivate or suspend agents based on lifecycle events, risk signals, or manual triggers from a human sponsor
• Identity Governance (OIG) — Access Requests: human approval workflows gate agent creation and any expansion of permissions; no agent gains access without a named human sponsor signing off
• Identity Governance (OIG) — Certification Campaigns: scheduled or event-triggered reviews require human attestation that each agent’s access remains appropriate; non-attested agents are automatically deprovisioned
• MFA step-up (CIBA) for sensitive agent operations adds a human verification checkpoint at runtime

Accountability & Governance (Article 17)

#

Requirement: Assign responsibility for AI system compliance and operation.

Blueprint reference:

• Agent lifecycle management — governed onboarding, review, and retirement of every agent
• AI agent risk detection — continuous assessment of agent privilege and behaviour risk
• Browser based detection - visibility for shadow AI agents that bypass identity controls, with workflows to bring them into compliance

Okta Solution:

• Universal Directory (UD): agents are provisioned as distinct identity types with mandatory owner attributes, ensuring accountability is built into the identity model. Every agent registered in Okta must have a named human owner — accountability is structural, not optional
• Lifecycle Management (LCM): automated workflows — from creation to modification (change history tracked) to deactivation (automatic on lifecycle events or manual by owner)
• Identity Governance (OIG) — Access Requests: documented approval chain for agent provisioning creates an auditable record of who authorized what, and when
• Identity Governance (OIG) — Certification Campaigns: periodic human review enforces lifecycle discipline; agents that are no longer needed are deprovisioned on a regular cadence
• Privileged Access (OPA): Service Accounts credentials are vaulted and rotated, eliminating the risk of orphaned or misused secrets that could lead to unaccountable agent actions
• Identity Security Posture Management (ISPM): continuous scanning of the identity layer detects over-privileged agents, dormant credentials, and policy violations that could indicate a drift from the intended governance model - ISPM risk scoring surfaces agents accumulating excessive permissions for immediate remediation

Cybersecurity Requirements (Annex IV)

#

Requirement: AI systems must be resilient to attacks, adversarial manipulation, and unauthorized access.

Blueprint reference:

• Runtime enforcement — scope and policy enforcement at the moment of execution
• AI agent risk detection — real-time anomaly and threat signals
• Agent Integration (MCP Server, SaaS Services, Agent-to-Agent Connections) — secure authentication and least-privilege access patterns
• Service Accounts and Valuted Credentials — secrets managed outside the agent, never embedded
• Kill Switch — immediate revocation of agent access

Okta Solution:

• Privileged Access (OPA): credential vaulting eliminates static secrets embedded in agent code; automated rotation minimises the exposure window for any credential
• API Access Management: OAuth 2.0 scopes enforce least-privilege at the API gateway — an agent can only call what its token explicitly permits
• Identity Security Posture Management (ISPM): continuous scanning of the identity layer detects misconfigurations, over-privileged agents, dormant credentials, and drift from policy baselines
• Identity Threat Protection (ITP): real-time behavioural analytics detect anomalous agent activity (unusual data volumes, off-hours access, lateral movement) and can trigger automated remediation or Universal Logout
• MFA on agent credential issuance adds an additional authentication layer for privileged operations

Risk Management (Article 9)

#

Requirement: Establish and maintain a risk management system throughout the AI system lifecycle.

Blueprint reference:

• AI agent risk detection — inventory and risk-score every agent
• Runtime enforcement — apply risk-based controls dynamically

Okta Solution:

• ISPM posture analysis produces a continuous risk inventory: which agents exist, what they can access, and where policy violations exist
• ITP risk signals feed dynamic risk scoring — privilege level, access frequency, data sensitivity, and behavioural anomalies all contribute to a per-agent risk score
• O4AA risk signals pipeline aggregates inputs from ISPM, ITP, and external threat intelligence into a unified view of agent risk
• Governance workflows in OIG translate risk scores into automated actions: flag for review, trigger certification, or initiate deprovisioning
• Continuous monitoring and alerting close the loop between detection and response across the agent lifecycle

Data Governance (Article 10)

#

Requirement: Implement data governance practices covering which data AI systems can access and how it is processed.

Blueprint reference:

• Vaulted credentials — agents never hold persistent data access credentials
• Runtime enforcement — data permissions enforced at call time, not embedded in the agent

Okta Solution:

• API Access Management: scope-based OAuth 2.0 tokens restrict each agent to the exact data endpoints it is authorised to call — no implicit or inherited access
• Fine-grained authorization (FGA): relationship-based access control enforces data access at the object level, ensuring agents can only read or write records they are explicitly permitted to touch
• Privileged Access (OPA): data store credentials (database passwords, API keys) are vaulted and injected at runtime — agents never have standing access to sensitive data
• System Log produces a complete record of every data access event by every agent, meeting the documentation requirements of Article 10 for training, validation, and production datasets

NIST AI RMF Alignment

#

For organizations that operate globally — or that already follow NIST frameworks for cybersecurity or software development — the NIST AI Risk Management Framework (AI RMF 1.0)⁷, published in January 2023, provides a voluntary but widely adopted companion to the EU AI Act’s mandatory requirements.

The AI RMF is organized around four core functions:

Although the NIST AI RMF is a US framework and voluntary in nature, it is increasingly referenced by EU regulators and auditors as a recognized best practice methodology. It also aligns structurally with EU AI Act Article 9 (risk management systems), providing a useful bridge for multinational organizations that must satisfy both frameworks.

Complementary references:

• NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models⁸
• NIST AI RMF Playbook — Practical implementation guidance mapped to each core function

Regulatory Convergence: NIS2 and DORA

#

The EU AI Act does not operate in isolation. Organizations in regulated sectors face stacked obligations: EU AI Act compliance intersects with NIS2 and DORA in ways that share a common denominator — identity governance.

NIS2 (Directive 2022/2555)

#

The NIS2 Directive applies to essential and important entities across critical sectors: energy, finance, health, transport, digital infrastructure, and public administration. AI agents operating in these sectors trigger NIS2 obligations that are inseparable from identity:

• Article 21 — Mandatory risk management measures including access control, authentication, and asset management for all ICT systems
• Supply chain security — Organizations must govern third-party AI components and the identities they carry
• Incident reporting — Significant incidents must be reported within 24 hours (early warning) and 72 hours (full report); an AI agent malfunction can qualify if it causes a security breach or significant disruption to services — though NIS2 does not reference AI explicitly, and not every agent malfunction meets the reporting threshold

Identity intersection: An AI agent that bypasses MFA, acts outside its authorized scope, or cannot be traced in an audit log is a NIS2 compliance failure, not just a security incident.

DORA (Regulation 2022/2554)

#

The Digital Operational Resilience Act applies to financial entities — banks, insurers, payment institutions, crypto-asset service providers, and their critical ICT third-party providers. AI agents in FinTech and FinServ must meet:

• Article 9 — Information security requirements including identity and access management, strong authentication, and privileged access controls
• Article 28 — Third-party ICT risk management: documented access governance, audit rights, and contractual oversight for any AI provider with access to financial systems
• Resilience testing — DORA requires regular testing of ICT systems, including AI agent behaviors under stress or adversarial conditions

Identity intersection: DORA’s requirements for documented access control, immutable audit trails, and contractual accountability for third-party access map directly to what O4AA provides through OIG, System Log, and API Access Management.

A coordinated investment in O4AA-based AI identity governance addresses the shared identity-layer requirements across EU AI Act, NIS2, and DORA — reducing duplication and avoiding siloed compliance initiatives. Identity governance is a necessary component across all three frameworks; it does not replace the organisational governance, process documentation, and additional technical controls that each regulation also requires.

GDPR and Data Processed by Agents

#

AI agents that process personal data trigger GDPR obligations independently of their AI Act classification — making it the one framework every agent, at any risk level, must verify compliance with:

• Lawfulness of processing: every agent action on personal data must have a legal basis
• Data minimization: agents must access only the data strictly necessary for the task — O4AA’s least-privilege principle is directly aligned with this obligation
• Data subject rights: the organization must be able to respond to access, rectification, and erasure requests even for data processed by AI systems — which requires the traceability that O4AA provides

Implementation Roadmap for EU AI Act Compliance

#

You don’t have to wait until August 2026 to start closing the attribution gap. The compliance requirements outlined above are not just future obligations — they are current best practices for responsible AI deployment. Organizations that delay risk falling into the “shadow AI” trap, where agents proliferate without governance, creating a ticking time bomb of non-compliance.

1. Discovery & Assessment — Establish baseline visibility and identify compliance gaps

   • Enable Shadow AI Discovery to catalog all AI agents
   • Assess each agent against EU AI Act risk categories
   • Identify high-risk agents requiring immediate governance
   • Document current audit and logging capabilities
   Okta Tools

   Shadow AI Agent Discovery, ISPM, Universal Directory

2. Governance & Accountability — Establish ownership and oversight mechanisms

   • Assign human sponsors to all AI agents
   • Implement OIG Access Request workflows for agent creation and any permission expansion
   • Launch OIG Certification Campaigns for existing agents to attest or deprovision
   • Establish Universal Logout procedures
   Okta Tools

   OIG, Workflows, Universal Directory, Universal Logout

3. Runtime Controls & Monitoring — Enforce least-privilege and enable real-time oversight

   • Implement scope-based API Access Management with XAA / ID-JAG
   • Deploy ITP for behavioral analytics and anomaly detection
   • Configure SIEM integration for audit log retention
   • Establish alerting for policy violations
   Okta Tools

   XAA, API Access Management, ITP, ISPM, System Log

4. Continuous Compliance — Maintain posture and adapt to regulatory updates

   • Schedule regular OIG Certification Campaigns to catch drift
   • Monitor ISPM dashboards for over-privileged agents and dormant credentials
   • Conduct periodic compliance audits
   • Update policies based on regulatory guidance
   Okta Tools

   OIG, ISPM, Workflows

---
config:
  theme: 'base'
---
timeline
    title EU AI Act Compliance Roadmap — Identity Layer
    Phase 1 · Discovery : Shadow AI Discovery : ISPM posture scan : Agent inventory
    Phase 2 · Governance : OIG Access Requests : Certification Campaigns : Universal Logout
    Phase 3 · Runtime : XAA / ID-JAG : API Access Management : ITP + SIEM
    Phase 4 · Continuous : Scheduled certifications : ISPM drift monitoring : Policy updates

Conclusions

#

What Matteo’s article and this one share — despite their different angles — is the same underlying message: compliance doesn’t happen by accident. It requires deliberate architecture, and for AI agents that architecture starts with Identity.

The EU AI Act creates clear obligations, but organizations in regulated sectors face more than one framework. A bank deploying an AI agent for credit risk is simultaneously subject to EU AI Act (if high-risk), NIS2 (as a financial entity managing ICT risk), and DORA (for ICT resilience and third-party oversight). The identity requirements embedded in each regulation overlap significantly. Solving them once — at the identity layer — is more efficient and more durable than addressing each regulation in isolation.

Okta’s O4AA — Agentic Enterprise Blueprint provides that unified foundation:

• Comprehensive traceability via audit logs and SIEM integration (EU AI Act Art. 12, NIS2 Art. 21, DORA Art. 9)
• Human oversight through approval workflows and Universal Logout (EU AI Act Art. 14, NIST MANAGE)
• Clear accountability with mandatory ownership attribution (EU AI Act Art. 17, DORA Art. 28, NIST GOVERN)
• Cybersecurity resilience through ISPM, ITP, and credential management (EU AI Act Annex IV, NIS2/DORA Art. 9)

The August 2026 deadline is not far. For organizations still in the shadow AI phase — where agents are deployed without governance — the gap between current state and compliance readiness is significant. The frameworks covered here (EU AI Act, NIST AI RMF, NIS2, DORA) are not bureaucratic overhead. They are a blueprint for the kind of AI deployment that organizations, regulators, and end users can actually trust.

What’s your organization’s compliance posture today? Are you ahead of the curve — or still mapping which agents you even have? 👇

✋ Next Steps

#

Learn More

#

• Securing AI: Okta’s Blueprint for the Secure Agentic Enterprise — O4AA Series 1: why AI agents need first-class identity governance
• Okta for AI Agents: Access Patterns — O4AA Series 2: how agents authenticate to enterprise resources
• Agentic Enterprise Blueprint: Download the complete framework guide
• EU AI Act Full Text: Official regulation text
• NIST AI RMF 1.0: The NIST AI Risk Management Framework
• The Attribution Gap: AI Regulation (Okta) — how the inability to trace agent actions to authorized humans creates legal and regulatory exposure
• EU AI Act Explorer — interactive guide to the regulation: articles, recitals, obligations by role, and compliance timelines
• OWASP Top 10 for Large Language Model Applications — the canonical security risk list for LLM-based systems; directly relevant to agent threat modelling and Annex IV cybersecurity obligations

💬 Join the Conversation

#

How is your organization preparing for EU AI Act compliance? What challenges are you facing with AI agent governance?

Share your experience in the comments below or connect with me on LinkedIn to continue the discussion.

From Overview to Implementation

#

In Part 2 of this series I introduced the four access patterns that Okta for AI Agents (O4AA) provides — XAA, STS, PSK, and Service Account — and the strategic framework for choosing between them. That article answered which pattern and why.

This deep dive answers how. For each pattern I walk through the protocol flow, the sequence diagrams, the token structure (where applicable), the audit signals you should expect in Okta system logs, the use cases where it fits, and the concrete configuration steps in the Okta admin console. If you are an architect or solution engineer about to implement one of these patterns, this is the reference companion to keep open in a second tab.

Cross App Access (XAA)

#

Cross App Access (XAA) is the flagship access pattern for Okta for AI Agents. It implements user-delegated, user-context-aware access through the Identity Assertion JWT Authorization Grant (ID-JAG), an emerging IETF standard for secure delegation¹.

Why XAA Matters

#

XAA is the first access pattern to embed full identity context at every hop in an agent workflow. Every token carries both:

• sub: The user identity (who authorized this action)
• act.sub: The agent identity (which agent is acting on their behalf)

This dual-identity structure enables capabilities impossible with traditional service accounts:

• Per-user audit attribution: Every agent action is traceable to the specific user who authorized it
• Surgical revocation: Disable one user’s access to one agent without affecting other users or agents
• Scope narrowing: The token’s effective permissions are the narrowest overlap of what the agent is allowed, what the user is entitled to, and what the specific task requires
• Regulatory compliance: Complete audit trails satisfying NIST SP 800-63-4², EU AI Act³, NIS2⁴, and DORA⁵ traceability requirements

How XAA Works: The ID-JAG Flow

#

The XAA flow involves a token exchange sequence where Okta vouches for the user’s identity to the target resource’s authorization server.

sequenceDiagram
    autonumber
    actor User
    participant Client as 🤖 Client
(AI Agent)
    box rgba(243, 242, 247,0.3) Okta Cloud
        participant IdP as 🔐 IdP AS
(Okta Org AS)
        participant AS as 🛡️ Resource AS
(Custom AS)
    end
    participant RS as 📦 Resource Server
(Protected API)

    Note over User, RS: Step 1: User Authentication (OIDC SSO)
    User->>Client: Initiate action
    Client->>IdP: Auth Code + PKCE
    IdP->>User: Authenticate (MFA)
    User-->>IdP: Credentials
    IdP-->>Client: ID Token + Refresh Token
    Note left of IdP: sub:user
aud:client

    Note over User, RS: Step 2: Token Exchange (RFC 8693)
    Client->>IdP: Token Exchange Request
    Note right of Client: grant_type:token-exchange
subject_token:ID_Token
requested_token_type:id-jag
audience:Resource AS
    IdP->>IdP: Validate ID Token
    Note right of IdP: private_key_jwt
managed connection policy
    IdP->>IdP: Generate ID-JAG
    IdP-->>Client: ID-JAG (Identity Assertion)
    Note left of IdP: sub:user
aud:Resource AS
client_id:agent

    Note over User, RS: Step 3: JWT Bearer Grant (RFC 7523)
    Client->>AS: JWT Bearer Request
    Note right of Client: grant_type:jwt-bearer
assertion:ID-JAG
scope:orders:read
    AS->>AS: Validate ID-JAG
    Note left of AS: aud match
client_id match
signature (JWKS)
    AS->>AS: Apply Authorization Policy
    AS-->>Client: Access Token
    Note left of AS: sub + act.sub + scope
ephemeral

    Note over User, RS: Step 4: API Call
    Client->>RS: API call (with Access Token)
    RS->>RS: Validate Token (JWKS)
    RS-->>Client: Response data

Step-by-step breakdown

#

1. User authentication (OIDC SSO): The user initiates an action through the client application. The client redirects to Okta’s Org Authorization Server using Authorization Code + PKCE. The user authenticates (including MFA if configured), and Okta issues an ID Token and optionally a Refresh Token. This ID Token becomes the subject_token for the next step.
2. Token exchange at Okta (RFC 8693): The agent authenticates with its workload credentials (private_key_jwt) and requests a token exchange (grant_type: token-exchange, subject_token: ID Token, requested_token_type: id-jag, audience: Custom AS). Okta validates the token, checks the managed connection policy, and generates an ID-JAG — a signed JWT containing sub (user), aud (Custom AS), and client_id (agent).
3. JWT Bearer grant at Custom AS (RFC 7523): The agent presents the ID-JAG to the Custom AS’s token endpoint (grant_type: jwt-bearer, assertion: ID-JAG, scope: orders:read). The Custom AS validates the ID-JAG signature via JWKS, confirms aud and client_id match, applies its local authorization policy, and mints an ephemeral access token with sub + act.sub.
4. API call: The agent calls the protected resource with the scoped access token. The resource validates the token via JWKS and returns data.

User Presence and Consent Model

#

A key advantage of XAA is that it eliminates the interactive consent step at the Resource Authorization Server. Unlike traditional OAuth flows where each resource requests user consent separately, in XAA the IdP evaluates administrator-defined policies and delegates authorization authority. The Resource AS trusts the IdP’s assertion without prompting the user — this is what oauth.net describes as enabling access “without any user interaction” at the resource level.

However, XAA does require user authentication to bootstrap the flow. The user must authenticate via OIDC SSO (Step 1) so the agent obtains an ID Token as subject_token for the token exchange. Every agent action is scoped to a specific authenticated user’s identity and permissions.

The ID-JAG Standard

#

ID-JAG (Identity Assertion JWT Authorization Grant) is based on several IETF standards:

• RFC 8693: OAuth 2.0 Token Exchange
• RFC 7523: JWT Profile for OAuth 2.0 Client Authentication
• IETF ID-JAG Draft: Identity Assertion JWT Authorization Grant specification (active IETF working group draft)

For a comprehensive overview of Cross App Access and how it fits into the OAuth ecosystem, see the OAuth.net Cross App Access reference.

The key innovation is the clean separation of user identity (sub) and agent identity (client_id) as distinct required claims in the ID-JAG token. The IdP signs an assertion that says “user X has authorized agent Y to act on their behalf for resource Z” — all in a single, verifiable JWT. Downstream, the Resource AS can mint access tokens with the act claim (per RFC 8693 §4.4) to propagate this separation to resource servers, enabling a clear audit trail of “who is this action for” versus “what system is performing the action.”

Token Structure

#

The XAA flow produces two distinct tokens. Understanding the difference is important for implementation and audit.

The ID-JAG Token (issued by the IdP)

#

The ID-JAG is a signed JWT issued by the IdP Authorization Server during the token exchange (Step 1). It asserts the user’s identity and the agent’s authorization to act on their behalf. Its JWT header must use the type oauth-id-jag+jwt.

Header: { "typ": "oauth-id-jag+jwt", "alg": "RS256" }

{
  "iss": "https://acme.okta.com",
  "sub": "john@example.com",
  "aud": "https://crm.example.com/oauth2",
  "client_id": "sales-representative-agent",
  "jti": "9e43f81b64a33f20116179",
  "exp": 1735571612,
  "iat": 1735571312,
  "resource": "https://crm.example.com/api",
  "scope": "orders:read accounts:read",
  "auth_time": 1735571200,
  "amr": ["mfa", "pwd"]
}

The Access Token (issued by the Resource AS)

#

The Resource AS validates the ID-JAG (Step 2) and issues a scoped access token. This token propagates the delegation via the act claim (RFC 8693 §4.4), making both identities visible to the resource server:

{
  "sub": "john@example.com",
  "act": {
    "sub": "sales-representative-agent",
    "aud": "okta.com"
  },
  "aud": "crm-orders-api",
  "scope": "orders:read accounts:read",
  "jti": "s2r3d4x3m6a0q1l",
  "iat": 1735571312,
  "nbf": 1735571312,
  "exp": 1735571468
}

Token Lifetime

#

The ID-JAG specification requires the exp (expiration) and iat (issued at) claims in every token, but it does not mandate a specific lifetime. The "expires_in": 300 (5 minutes) that appears in the spec is marked as RECOMMENDED in the token exchange response — it is an example, not a fixed requirement.

In practice, the IdP administrator configures the token lifetime based on the deployment’s security posture. A shorter lifetime (e.g. 5 minutes) limits the blast radius if a token is compromised; a longer lifetime reduces the frequency of token exchanges for agents performing multi-step workflows. The right value depends on your risk profile, but the design intent is clear: ID-JAG tokens should be short-lived and re-issued frequently, not cached for hours.

Audit and Compliance Benefits

#

When using XAA, Okta’s system logs capture rich context for every access event, including both the user and agent identities, the scopes requested, the target resource, and a unique transaction ID for correlation. The EventType app.oauth2.token.grant.id_jag specifically indicates when an ID-JAG exchange occurred, providing a clear audit trail for agent actions.

Let’s see an example of an actual XAA event log entry from Okta’s system logs:

{
  "actor": {
    "id": "wlpxnnu00000B6vxs1d7",
    "type": "PublicClientApp",
    "alternateId": "unknown",
    "displayName": "Pricing Agent",
    "detailEntry": null
  },
  "client": {
    "userAgent": {
      "rawUserAgent": "python-requests/2.33.1",
      "os": "Unknown",
      "browser": "UNKNOWN"
    },
    "zone": "null",
    "device": "Unknown",
    "id": null,
    "ipAddress": "x.x.x.x",
    "geographicalContext": {
      "city": "Ashburn",
      "state": "Virginia",
      "country": "United States",
      "postalCode": "20149",
      "geolocation": {
        "lat": 39.0469,
        "lon": -77.4903
      }
    }
  },
  "displayMessage": "OAuth 2.0 Identity Assertion Authorization Grant is granted",
  "eventType": "app.oauth2.token.grant.id_jag",
  "outcome": {
    "result": "SUCCESS",
    "reason": null
  },
  "published": "2026-04-16T19:27:49.919Z",
  "securityContext": {
    "asNumber": 14618,
    "asOrg": "amazon.com  inc.",
    "isp": "amazon.com  inc.",
    "domain": "amazonaws.com",
    "isProxy": false,
    "ipDetails": {
      "asNumber": 14618,
      "asOrg": "amazon.com  inc.",
      "isp": "amazon.com  inc.",
      "domain": "amazonaws.com"
    }
  },
  "severity": "INFO",
  "debugContext": {
    "debugData": {
      "clientAuthType": "private_key_jwt",
      "grantedScopes": "pricing:margin",
      "subjectTokenIssuer": "https://xxx.oktapreview.com",
      "subjectTokenType": "urn:ietf:params:oauth:token-type:id_token",
      "clientId": "wlpxnnu00000B6vxs1d7",
      "responseTime": "213",
      "requestedTokenType": "urn:ietf:params:oauth:token-type:id-jag",
      "authorizationServerAudience": "https://xxx.oktapreview.com/oauth2/ausxnnacdm60nV7vv1d7",
      "requestUri": "/oauth2/v1/token",
      "requestedScopes": "pricing:margin",
      "tokenExchangeType": "Agent ID Assertion",
      "url": "/oauth2/v1/token?",
      "managedConnectionId": "mcnxnodu9t2FRZO5R1d7",
      "subjectTokenId": "ID.kiJ9Ch3aBer2ftX2CobkLuSSPqBMdMsZaxwRMZQjr44",
      "subjectTokenClientId": "0oaxnnekviMmWpyBK2d3",
      "requestId": "5eaf3d96ff3dbb684e1099bf8cecdd53",
      "dtHash": "96dec87ffaebc55e64ab62eca30303c555d589e0f9686d55827963c51032ef7f",
      "threatSuspected": "false",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange"
    }
  },
  "legacyEventType": null,
  "transaction": {
    "type": "WEB",
    "id": "5eaf3d96ff3dbb684e1099bf8cecdd53",
    "detail": {}
  },
  "uuid": "5b10a39b-39ca-11f1-bbfb-f341db467931",
  "version": "0",
  "request": {
    "ipChain": [
      {
        "ip": "x.x.x.x",
        "geographicalContext": {
          "city": "Ashburn",
          "state": "Virginia",
          "country": "United States",
          "postalCode": "20149",
          "geolocation": {
            "lat": 39.0469,
            "lon": -77.4903
          }
        },
        "version": "V4",
        "source": null,
        "ipDetails": {
          "asNumber": 14618,
          "asOrg": "amazon.com  inc.",
          "isp": "amazon.com  inc.",
          "domain": "amazonaws.com"
        }
      }
    ]
  },
  "target": [
    {
      "id": "ID.kiJ9Ch3aBer2ftX2CobkLuSSPqBMdMsZaxwRMZQjr44",
      "type": "id_token",
      "alternateId": null,
      "displayName": "ID Token",
      "detailEntry": {
        "audience": "0oaxnnekviMmWpyBK2d3",
        "expires": "2026-04-16T20:07:29.000Z",
        "subject": "00uxnn7b13YEcYj2V6a7",
        "hash": "iMQM1uCzsH07nFhkRPUNvg"
      }
    },
    {
      "id": "00uxnn7b13YEcYj2V6a7",
      "type": "User",
      "alternateId": "fabio.grasso@example.com",
      "displayName": "Fabio Grasso",
      "detailEntry": null
    },
    {
      "id": "IDAAG.5ZazR5P-fmm8zuG1CwuqT3EenUx1pFfN00jToEE0s6A",
      "type": "id_jag",
      "alternateId": null,
      "displayName": "Identity Assertion JWT Authorization Grant",
      "detailEntry": {
        "audience": "https://xxx.oktapreview.com/oauth2/ausxnnacdm60nV7vv1d7",
        "expires": "2026-04-16T19:32:49.000Z",
        "subject": "00uxnn7b13YEcYj2V6a7",
        "scope": "pricing:margin",
        "hash": "Tq7wccRtqpRvZvEXKYK9nA"
      }
    }
  ]
}

As you can see, not only the agent that made the request (Pricing Agent) but also the user that authorized the action (fabio.grasso@example.com). The grantedScopes field shows the effective permissions granted to the agent for this request, which is the intersection of what the agent can do and what the user is entitled to. The jti claim in the token becomes the transaction.id in the logs, allowing you to correlate this event with downstream events in your resource’s logs if they also log the transaction ID.

XAA Use Cases

#

Let’s see some concrete examples of how XAA can be used to secure different types of resources:

1. Internal API via MCP Server - A customer support agent needs to access the internal order database to answer customer queries.
   • Agent registered in Okta Universal Directory
   • MCP Server protected by Okta Custom Authorization Server
   • XAA flow: Agent exchanges user’s ID Token for scoped access to orders:read
   • Audit: Every query logged with user ID, agent ID, and transaction ID
2. First-Party SaaS (ISV-Enabled) - A sales assistant agent accessing Salesforce opportunities on behalf of a sales rep.
   • Salesforce implements ID-JAG validation
   • Agent presents ID-JAG to Salesforce authorization endpoint
   • Salesforce issues scoped token for the user’s data only
   • No static credentials; no shared service accounts
3. Multi-Step Agent Workflows - A finance agent executes an approval workflow:
   • Step 1: Read expense report (read:expenses scope)
   • Step 2: Check budget availability (read:budgets scope)
   • Step 3: Submit approval (write:approvals scope)
   • Each step can request different scopes. If the agent is compromised mid-workflow, revocation stops only that user’s session without affecting others.

Testing XAA: The xaa.dev Playground

#

Okta provides an interactive testing environment at xaa.dev where you can experiment with XAA flows without infrastructure setup⁶.

Features:

• Browser-based testing (no Docker or local configuration)
• Pre-configured components: Requesting App, Resource App, IdP
• Get started in under 60 seconds
• Register your own custom clients for testing

The playground includes a sample flow where “Bob Tables” creates and manages tasks through an AI agent, demonstrating the full ID-JAG exchange.

ID-JAG and XAA: A Note on Naming

#

You’ve likely seen “ID-JAG” and “XAA” used interchangeably across documentation, blog posts, and conference talks. They’re closely related — but they sit at different levels of abstraction, and neither is an Okta-only thing.

Cross-App Access (XAA) is the informal name of the OAuth extension as a whole — the end-to-end pattern where an enterprise IdP brokers access between two applications and replaces the user’s manual approval step with a token exchange. It’s documented on oauth.net/cross-app-access/ and is being standardized through the IETF.

ID-JAG (Identity Assertion JWT Authorization Grant) is the formal IETF specification name. More precisely, it refers to the signed JWT assertion that moves between domains inside an XAA flow. XAA builds on the broader Identity and Authorization Chaining Across Domains draft and profiles it for interoperable enterprise use.

XAA is an open, multi-vendor extension. Current implementations listed on oauth.net include Okta (early access), Auth0, Athenz, and Keycloak (in progress), with clients such as Claude Code already adopting it. Okta has been a major driver of both the IETF effort and early industry adoption — which is why “XAA” is the term most people encounter first in Okta contexts — but the extension itself is not an Okta product name.

The practical takeaway: when you read Okta documentation, “XAA” describes Okta’s implementation of the extension. When you read the IETF draft or a third-party integration guide, “ID-JAG” refers to the underlying assertion grant that any organization can implement.

XAA Limitations

#

• ISV adoption in progress: XAA is GA on the Okta side, but third-party SaaS integrations require ISV support. Major vendors are actively implementing ID-JAG, building on XAA today ensures you’re ready when they ship.

• Token lifetime vs. long-running sessions: Tokens are intentionally short-lived (lifetime is configurable by the IdP administrator, not fixed by the spec). Agents performing multi-step workflows need to re-exchange tokens as they expire. This is by design (limits blast radius) but requires agents to handle token refresh gracefully.

• Not suitable for: Agents that must operate offline or cache credentials indefinitely. For these scenarios, consider STS with careful credential lifecycle management.

Secure Token Service (STS)

#

Secure Token Service (STS) enables agents to access third-party SaaS applications that support OAuth but haven’t yet adopted XAA. Okta acts as a secure broker, vaulting user-consented tokens in Okta Privileged Access (OPA) and providing short-lived federated access at runtime.

When to Use STS

#

• Third-party SaaS with OAuth support but no ID-JAG support yet (e.g., as today, GitHub, Google Workspace, Slack)
• User-level context is required for audit and compliance

How STS Works

#

sequenceDiagram
    autonumber
    actor User
    participant Client as 🤖 Client
(AI Agent)
    box rgba(243, 242, 247,0.3) Okta Cloud
        participant IdP as 🔐 IdP AS
(Okta Org AS)
        participant Vault as 🔑 OPA
(Token Vault)
    end
    participant SaaS as 📱 Third-Party SaaS

    Note over User, SaaS: Phase 1 — One-Time Consent (user-initiated)

    Note over User, SaaS: Step 1: SSO Authentication
    User->>Client: Login via SSO (OIDC)
    Client->>IdP: OIDC authentication
    IdP-->>Client: ID Token (sub: user@example.com)

    Note over User, SaaS: Step 2: OAuth Consent
    Client->>IdP: Request managed connection token
    IdP-->>Client: Consent URL (SaaS OAuth)
    Client-->>User: Redirect to SaaS consent
    User->>SaaS: Login and approve access

    Note over User, SaaS: Step 3: Token Vaulting
    SaaS-->>IdP: Authorization Code (callback)
    IdP->>SaaS: Exchange code for tokens
    SaaS-->>IdP: Access + Refresh Tokens
    IdP->>Vault: Store tokens (bound to user context)

    Note over Client, SaaS: Phase 2 — Runtime Access (agent-autonomous, RFC 8693)

    Note over Client, SaaS: Step 4: Token Exchange (RFC 8693)
    Client->>IdP: Token Exchange Request
    Note right of Client: grant_type:token-exchange
subject_token: (vaulted user token)
actor: workload identity
audience: Third-Party SaaS
auth: private_key_jwt
    IdP->>IdP: Validate managed connection policy
    IdP->>Vault: Retrieve user-consented tokens
    Vault-->>IdP: Access + Refresh Tokens
    IdP->>SaaS: Refresh token if expired
    SaaS-->>IdP: Fresh Access Token
    IdP-->>Client: Short-lived federated token
    Note left of IdP: scope: connection-scoped
token_type: Bearer
expires_in: short-lived

    Note over Client, SaaS: Step 5: API Call
    Client->>SaaS: API call with token
    SaaS-->>Client: Response

Step-by-step breakdown

#

1. User authenticates (SSO): The user logs in through the Client via OIDC. Okta issues an ID Token with the user identity (sub: user@example.com).
2. Consent redirect: The Client requests a managed connection token. Okta returns a consent URL; the Client redirects the user to the SaaS’s standard OAuth consent screen.
3. User approves: The user logs in to the third-party SaaS and approves the requested scopes. The SaaS returns an authorization code to Okta’s callback endpoint.
4. Token vaulting: Okta exchanges the authorization code for access and refresh tokens and stores them in Okta Privileged Access (OPA), bound to the user’s identity context.
5. Runtime access (agent-autonomous — no live user session required): The agent authenticates to Okta with its workload identity (private_key_jwt) and requests access via the managed connection policy.
6. Token retrieval: Okta retrieves the vaulted tokens from OPA, refreshes them with the SaaS if expired, and issues a short-lived federated token to the agent.
7. API call: The agent calls the third-party SaaS with the short-lived token. User credentials never touch the agent.

STS Use Cases

#

1. GitHub — A coding assistant agent reads repositories and creates pull requests on behalf of developers. The developer consents once via GitHub’s OAuth screen; Okta vaults the resulting tokens. At runtime, the agent receives a short-lived federated token to call GitHub’s API — it never holds long-lived GitHub credentials.
2. Google Workspace — A scheduling agent manages calendar events and drafts emails for a user. User context is preserved through the consent flow, so Google’s audit logs capture which user authorized the agent’s actions.
3. Jira/Confluence — A project management agent creates tickets from Slack conversations and updates documentation pages. The agent authenticates through Okta’s brokered token, never storing Atlassian credentials directly.

Key difference from XAA

#

• Consent flow: STS requires the user to go through the third-party’s OAuth consent screen; Okta then stores and manages those tokens on behalf of the agent. XAA skips the consent screen entirely. Delegation happens at agent registration time in Okta.
• Audit trail: STS captures user consent and agent access in Okta logs, but the third-party service may only see the agent identity. XAA provides full user+agent context to the resource.
• Token lifetime: The federated token issued to the agent is short-lived (minutes) to limit risk, but the underlying access/refresh tokens in Okta may have longer lifetimes depending on the third-party service’s policies.
• Revocation: Revoking access requires deleting the vault entry in Okta, which may affect all agents using that connection. No per-user revocation within the third-party service.
• Scope narrowing: The agent receives whatever scopes the user consented to during the OAuth flow. Okta can’t dynamically narrow scopes per request like XAA.

Pre-Shared Key (PSK) or Vaulted Secret

#

Pre-Shared Key (PSK) stores static credentials (API keys, bearer tokens, webhook secrets) in Okta Privileged Access (OPA). The agent retrieves secrets at runtime rather than embedding them in code or configuration.

When to Use Pre-Shared Key

#

• Legacy REST APIs that only support API key authentication
• Webhook endpoints requiring bearer tokens
• Third-party integrations with static token auth
• Early-phase services that will eventually add OAuth

How Pre-Shared Key Works

#

sequenceDiagram
    autonumber
    actor Admin as Admin
    participant Client as 🤖 Client
(AI Agent)
    box rgba(243, 242, 247,0.3) Okta Cloud
        participant IdP as 🔐 IdP AS
(Okta Org AS)
        participant Vault as 🔑 OPA
(Secret Vault)
    end
    participant RS as 📦 Resource Server
(Protected API)

    Note over Admin, Vault: Phase 1 — Configuration (admin-initiated)
    Admin->>Vault: Create & vault secret (API key)
    Admin->>IdP: Create managed connection on agent (type: Secret)

    Note over Client, RS: Phase 2 — Runtime Access (agent-autonomous)
    Client->>IdP: Authenticate (workload identity)
    Note right of Client: private_key_jwt
managed connection policy
    IdP->>IdP: Validate managed connection policy
    IdP->>Vault: Retrieve vaulted secret
    Vault-->>IdP: API key / bearer token
    IdP-->>Client: Release secret
    Client->>RS: API call with secret
    RS-->>Client: Response

Step-by-step breakdown

#

1. Admin vaults the secret: An administrator stores the API key or bearer token in Okta Privileged Access and creates a managed connection on the agent (type: Secret)
2. Agent authenticates: At runtime, the agent authenticates to Okta with its workload principal identity
3. Policy check: Okta validates the agent’s identity and checks the managed connection policy
4. Secret released: Okta releases the vaulted credential to the agent
5. Direct resource access: The agent uses the static credential to call the downstream resource directly — no token exchange, no user context

Pre-Shared Key Limitations

#

• No user context: Resource sees agent identity only, not the user
• No scope narrowing: Agent has full access granted to the credential
• Limited audit trail: Logs show agent access, not user attribution

Service Account

#

Service Account uses username and password credentials linked to a service identity stored in Okta Privileged Access (OPA). Okta’s official documentation is explicit: “because this method uses username and password credentials to grant access to AI agents, it’s the least secure choice and isn’t recommended.” This is the legacy pattern that Okta explicitly recommends migrating away from.

How Service Account Works

#

sequenceDiagram
    autonumber
    actor Admin as Admin
    participant ClientA as 🤖 Client A
(AI Agent)
    participant ClientB as 🤖 Client B
(AI Agent)
    box rgba(243, 242, 247,0.3) Okta Cloud
        participant IdP as 🔐 IdP AS
(Okta Org AS)
        participant Vault as 🔑 OPA
(Credential Vault)
    end
    participant RS as 📦 Resource Server
(Protected API)

    Note over Admin, RS: Phase 1 — Configuration (admin-initiated)
    Admin->>Vault: Create service account (svc_agent@example)
    Admin->>ClientA: Register with managed connection
    Admin->>ClientB: Register with managed connection

    Note over ClientA, RS: Phase 2 — Runtime Access (agent-autonomous)
    ClientA->>IdP: Request credentials
    ClientB->>IdP: Request credentials
    Note right of ClientA: private_key_jwt
managed connection
    IdP->>IdP: Validate managed connection policy
    IdP->>Vault: Retrieve vaulted credentials
    Vault-->>IdP: Username/Password (svc_agent@example)
    IdP-->>ClientA: Username/Password
    IdP-->>ClientB: Username/Password
    ClientA->>RS: Authenticate as svc_agent@example
    ClientB->>RS: Authenticate as svc_agent@example

    Note over RS: Both appear as same identity!

Step-by-step breakdown

#

1. Admin provisions service account: An administrator creates a service account in OPA (Credential Vault) and registers managed connections on one or more agents
2. Agents request credentials: At runtime, each agent authenticates to the IdP AS with its workload identity (private_key_jwt) and requests the service account credentials via the managed connection
3. Okta releases username/password: The IdP AS retrieves the vaulted credentials from OPA, validates the agent’s identity, checks policy, and hands over the shared credentials
4. Agent authenticates to resource: The agent logs into the Resource Server as the service account — indistinguishable from any other agent using the same credentials

Service Accounts Limitations

#

Service Accounts present four critical security gaps:

1. Invisible agents: Multiple agents share a single identity, making it impossible to tell which one performed an action
2. Excessive permissions: Service accounts typically carry broad, static privileges that far exceed what any single task requires
3. Missing user attribution: Compliance audits can’t answer “which user triggered this data access?”
4. All-or-nothing revocation: Deactivating the service account kills access for every agent and system that depends on it

When Service Account is Unavoidable

#

• Legacy systems requiring username/password authentication (on-prem databases, mainframes, LDAP-backed services)
• Batch processing with no end-user context
• Systems that have not adopted any modern authentication method

Service Account is acceptable only for batch processes with no user context, with a documented sunset plan.

Service Account vs Pre-Shared Key

#

Both patterns are Managed Connections backed by Okta Privileged Access, and neither carries user context or scope narrowing. The confusion is legitimate: at a glance they do the same thing. The difference becomes clear once you look at what is stored in OPA, what the agent receives, and what the downstream resource sees.

In one sentence: PSK is a machine-native credential with an API-only surface; Service Account is a real user identity that gets borrowed, with all the attack surface of a human account (even with auto-rotation and checkout/checkin enabled). Both are “reusable” by an attacker who exfiltrates them — an API key works with curl too — but a user password opens many more doors: interactive login, account recovery, long-lived sessions, and privileges that usually go far beyond pure integration scope.

That is why moving from Service Account to PSK is the first defensible step on the migration ladder, even though neither pattern carries user context.

From Theory to Practice: Configuring Access Patterns in Okta

#

In Okta’s Universal Directory, you can register AI agents as workload identities and create Managed Connections that define how they access downstream resources. Each connection type corresponds to one of the access patterns I’ve discussed above.

AI Agents List	AI Agent Detail

When you create a managed connection, you’ll see five resource types. They map to the four access patterns covered in this article:

XAA Configuration Overview

#

Implementing XAA requires:

1. Register the agent in Okta Universal Directory as a workload principal
2. Create a Managed Connection and select “Authorization Server” (for custom APIs) or “MCP Server” (for MCP endpoints). Both use the same ID-JAG exchange under the hood.
3. Configure the Custom Authorization Server protecting your resource
4. Define RBAC policies that evaluate both user and agent attributes

Example policy logic, to ensure the agent can only access sales data when the user is a member of the sales team:

IF (act.sub == "sales-representative-agent")
AND (sub IN groups["sales-team"])
AND (requested_scope IN ["sales:read", "accounts:read"])
THEN issue_token_with_scope
ELSE deny

This is a pseudo-code example. In the Okta Admin Console, Custom Authorization Server access policies use a policy + rule model — not a scripting language. To follow the example you can:

1. Create an Access Policy assigned to the agent’s AI Agent (i.e., sales-representative-agent). This implicitly scopes the policy to that specific agent (act.sub).
2. Create a Rule within that policy:
   • Grant type: JWT Bearer (the ID-JAG exchange grant)
   • User eligibility: Users member of group: sales-team — this ensures only sales team members can delegate access through this agent
   • Scopes: Allowlist of orders:read and accounts:read — the agent can’t request broader scopes even if the user has them
   • Token lifetime: 5 minutes (ephemeral)
   • Evaluation: Policies and rules are evaluated in priority order. The first match wins. If no rule matches (e.g., a user outside sales-team tries to use this agent), the request is denied.

The result: the agent can only access sales data when the user behind the request is a member of the sales team. The effective permissions are the intersection of the policy’s scope allowlist, the user’s group membership, and the agent’s managed connection.

STS Configuration

#

In the Okta admin console, you configure STS by creating a managed connection with the “Application” resource type, selecting an OIN app integration or a custom resource server⁷. Okta then brokers the OAuth token exchange between the agent and the third-party service.

Pre-Shared Key Configuration

#

In the Okta admin console, you configure PSK by creating a managed connection with the “Secret” resource type. The API key or bearer token must first be stored in Okta Privileged Access; the managed connection then references that vaulted secret. At runtime, the agent retrieves the credential on demand — it is never hardcoded in the agent’s code or configuration.

Service Account Configuration

#

In the Okta admin console, you configure a Service Account connection by creating a managed connection with the “Service Account” resource type, linking it to a service account identity stored in Okta Privileged Access. Because multiple agents can reference the same service account, treat this as a last resort and document a clear sunset plan before deploying it.

Where to Next

#

You now have the protocol-level toolkit for every Okta for AI Agents pattern. Two natural next stops:

• Back to the strategic view: re-read Part 2 — Access Patterns with the implementation details fresh in mind. The decision framework and migration ladder make a lot more sense once you’ve seen the token claims and sequence diagrams.
• Forward to compliance: in Part 4 — EU AI Act Compliance I map each pattern to the regulatory requirements (EU AI Act, NIST AI RMF, NIS2, DORA), showing how the audit fields you’ve just learned to read translate directly into compliance evidence.

Try It Live

#

Explore the interactive XAA playground at xaa.dev — no setup required. Spin up agents, perform ID-JAG exchanges, and inspect the resulting tokens directly in your browser.

Reference Library

#

• Cross App Access Documentation — Official Okta configuration guide
• XAA.dev Documentation — Interactive playground docs
• Cross App Access Introduction — Technical introduction
• XAA Developer Playground — Hands-on tutorial
• Building Resource Apps — Implementation guide
• AI Agent Token Exchange Guide — Step-by-step developer guide
• Secure AI agent access to resources — Okta Help Center
• OAuth.net — Cross-App Access — Vendor-neutral overview of the XAA extension, list of implementations, and related IETF specs

Join the Conversation

#

Which pattern are you implementing first? Hitting any blockers on ID-JAG exchange or managed connection policies? Drop a note in the comments below or reach out on LinkedIn.

Choosing the Right Access Pattern

#

In my previous article on the Agentic Enterprise Blueprint, I explored how Okta positions AI agents as first-class identities within the enterprise security fabric. I examined the strategic framework answering three foundational questions: Where are my agents? What can they connect to? What can they do?

But strategy without execution is just theory. Now I want to answer a more practical question: How should AI agents authenticate and authorize their communications with enterprise resources?

This guide is designed to help architects, security teams, and solution engineers evaluate the four access patterns Okta for AI Agents provides for AI agent integrations. By the end, you’ll understand:

• Which pattern fits your security requirements (user context, scope narrowing, audit trails)
• Which pattern your resources support (ID-JAG, OAuth, API keys, or username/password)
• How to compare security levels between patterns
• When to migrate from legacy patterns to modern approaches

This question isn’t academic. The access pattern you choose determines:

• Whether your audit logs capture user attribution: Can you trace an action back to both the agent and the user it acted for?
• Whether you can revoke access surgically: Can you disable a single user’s access to one agent without affecting others?
• Whether your architecture complies with regulatory requirements: Does your implementation satisfy NIST SP 800-63-4¹, the EU AI Act², NIS2³, DORA⁴ traceability mandates?

Consider this scenario: Your security team is investigating a data access incident. An AI agent accessed sensitive customer records at 3:47 AM. With the wrong access pattern, your audit logs might show only service-account-agent accessed database With the right pattern, you see sales-representative-agent, acting on behalf of john@example.com, accessed customer record #12847 with read scope, transaction ID jti-7z9x2q8.

Okta for AI Agents (O4AA) provides four distinct access patterns, each optimized for different security models, resource capabilities, and compliance requirements⁵. The choice isn’t arbitrary: it’s a fundamental architectural decision that shapes your agent security posture.

Let’s examine each pattern, understand when to use it, and see how they fit into a coherent access strategy.

Access Patterns at a Glance

#

The Okta for AI Agents (O4AA) platform offers four ways for an agent to reach a downstream resource. Each one is configured as a Managed Connection attached to the agent’s workload principal in Okta. Picking the right pattern comes down to three factors:

1. What does the downstream resource support? (XAA, ID-JAG, OAuth, API key, username/password)
2. Is user-level context required? (Audit attribution, per-user scope narrowing)
3. What are your security and governance requirements? (Compliance profile, revocation granularity)

The Four Patterns

#

Below is a brief overview of each pattern — what it does, when to use it, and the headline trade-off. For the full implementation guide (protocol flows, sequence diagrams, token claims, audit log examples, and Okta configuration walkthroughs) see the companion article: Access Patterns Deep Dive.

Cross App Access (XAA)

#

Cross App Access (XAA) is the flagship access pattern. It implements user-delegated, user-context-aware access through the Identity Assertion JWT Authorization Grant (ID-JAG)⁷, an emerging IETF standard. Every token carries both sub (the user) and act.sub (the agent) — enabling per-user audit attribution, surgical revocation, dynamic scope narrowing, and direct alignment with NIST SP 800-63-4¹, the EU AI Act², NIS2³, and DORA⁴.

• When to use it: internal APIs, MCP servers, and SaaS that has shipped ID-JAG support.
• Key benefit: full identity context at every hop. Effective permissions = intersection of agent rights, user entitlements, and per-request scopes.
• Limitation: ISV adoption for third-party SaaS is in progress.

👉 Deep dive: ID-JAG flow, token claims, audit logs, and configuration

Secure Token Service (STS)

#

Secure Token Service (STS) is the bridge for third-party SaaS that supports OAuth but hasn’t yet adopted ID-JAG. Okta acts as a secure broker: user-consented tokens are vaulted in Okta Privileged Access (OPA), and at runtime the agent gets a short-lived federated token. User context is preserved through the consent flow, so audit logs still capture who authorized the action.

• When to use it: third-party SaaS with standard OAuth (e.g. GitHub, Google Workspace, Atlassian) — until the vendor ships ID-JAG.
• Key benefit: user context without requiring ISV-side ID-JAG support; one-time consent enables fully autonomous Phase-2 operation.
• Limitation: scopes are fixed at consent time (no per-request narrowing); revocation is per-connection, not per-user.

👉 Deep dive: token vaulting flow, RFC 8693 exchange, comparison with XAA

Pre-Shared Key (PSK) or Vaulted Secret

#

Pre-Shared Key (PSK) stores static credentials (API keys, bearer tokens, webhook secrets) in Okta Privileged Access. The agent retrieves the secret at runtime instead of embedding it in code or configuration — and Okta can rotate it automatically when the downstream service supports it.

• When to use it: legacy REST APIs, webhook endpoints, or any service that authenticates only with API keys or bearer tokens.
• Key benefit: removes secrets from code; per-secret isolation gives at least agent-level attribution and surgical revocation.
• Limitation: no user context, no scope narrowing — audit logs see only the agent identity.

👉 Deep dive: secret retrieval flow, configuration, and migration path

Service Account

#

Service Account uses username/password credentials linked to a shared service identity. This is the legacy pattern Okta explicitly recommends migrating away from. Multiple agents typically share the same login, which breaks per-agent attribution and forces all-or-nothing revocation.

• When to use it: only when unavoidable — legacy systems (mainframes, on-prem databases, LDAP-backed services) that support nothing else, with a documented sunset plan.
• Key benefit: works with any system that accepts username/password.
• Limitation: no user context, no scope narrowing, shared identity, manual rotation. Every Service Account is a compliance gap.

👉 Deep dive: shared-identity flow, PSK comparison, and exit strategy

Strategic Recommendations

#

With the four patterns understood individually, the next step is to weigh them against each other and chart a migration path — the matrix, decision tree, and roadmap below pull it all together.

Pattern Comparison Matrix

#

Decision Framework

#

The framework prioritizes patterns by security posture: XAA provides the strongest guarantees, while Service Account represents the weakest (and should be treated as temporary).

---
config:
  layout: dagre
---
flowchart TB
    A["Does resource support ID-JAG?"] -- Yes --> XAA["✅ Use XAA
User-delegated, full audit,
surgical revocation"]
    A -- No --> B["Does resource support OAuth 2.0?"]
    B -- Yes --> STS["🔄 Use STS
User-consented token brokering"]
    B -- No --> C["Does resource support API keys?"]
    C -- Yes --> PSK["⚠️ Use PSK
Vaulted secret"]
    C -- No --> SA["🚫 Service Account
Only option - plan migration immediately"]

    A@{ shape: hex}
    B@{ shape: hex}
    C@{ shape: hex}
    style XAA fill:#d4edda,stroke:#28a745
    style STS fill:#E1BEE7,stroke:#0d6efd
    style PSK fill:#fff3cd,stroke:#ffc107
    style SA fill:#f8d7da,stroke:#dc3545

Implementation Sequencing

#

Here’s a recommended roadmap for transitioning to XAA while maintaining security and compliance:

• Phase 1: Audit existing integrations
  • Map all agent connections to one of the four patterns
  • Identify service accounts and pre-shared keys
• Phase 2: New integrations default to XAA
  • Use STS only when XAA isn’t supported
  • Use Service Account, or Pre-Shared Key only when absolutely necessary
  • Document rationale for non-XAA choices
• Phase 3: Monitor ISV roadmaps
  • As ISVs adopt ID-JAG, migrate STS connections to XAA
  • Track adoption announcements
• Phase 4: Service Account and Pre-Shared Key sunset
  • Establish formal deprecation timeline
  • Migrate to STS as intermediate step
  • Target zero service accounts for user-context workloads

Conclusions

#

The choice of access pattern isn’t a technical detail: it’s an architectural decision that shapes your AI agent security posture for years to come.

Key takeaways:

1. XAA is the future: User-delegated, auditable, compliant. Investing in XAA now means your architecture is ready for MCP Server and Agent-to-Agent support the moment they land.

2. STS bridges the gap: For third-party SaaS that supports OAuth but not ID-JAG, STS provides user context while you wait for ISV adoption.

3. Pre-Shared Key is acceptable for legacy: API-key-only services need vaulted secrets, but plan migration as resources modernize.

4. Service Account is technical debt: Every service account is a compliance gap waiting to surface in an audit. Start planning your exit.

The journey from Service Account → Pre-Shared Key → STS → XAA represents a security maturity progression. Each step up the ladder adds user context, scope narrowing, and audit granularity.

XAA will also be the foundation for future capabilities like Agent-to-Agent Access (A2A), Kill Switch (global token revocation), Human-in-the-Loop (HITL) workflows. Starting with XAA means you’re not just securing today’s integrations, but also future-proofing for tomorrow’s innovations.

Getting Started

#

Test XAA Today

#

Explore the interactive XAA playground at xaa.dev, no setup required. Experience the full ID-JAG flow in your browser.

Learn More

#

• Access Patterns Deep Dive: Companion article with full protocol details, sequence diagrams, audit log examples, and Okta configuration
• Okta for AI Agents: Platform overview
• Cross App Access Solution: XAA solution page
• Cross App Access Documentation: Official configuration guide
• XAA.dev Documentation: Interactive playground docs
• Cross App Access Introduction: Technical deep dive
• XAA Developer Playground: Hands-on tutorial
• Building Resource Apps: Implementation guide
• AI Agent Token Exchange Guide: Step-by-step developer guide for agent token exchange flows
• Agentic Enterprise Blueprint: Strategic governance framework
• Interactive Demo: Securing the Autonomous Enterprise: Demo

Join the Conversation

#

Which integrations in your environment are still using service accounts? Have you started mapping your agent connections to these access patterns? Where are you in that journey?

Share your experience in the comments below or connect with me on LinkedIn to continue the discussion.

The Identity gap in the age of AI Agents

#

The enterprise AI revolution is no longer coming, it’s here. Organizations worldwide are deploying AI agents that autonomously access data, make decisions, and execute actions at machine speed across corporate infrastructure. Yet beneath this acceleration lies a critical blind spot: 88% of organizations have experienced suspected or confirmed AI agent security incidents, but only 22% treat agents as independent identity-bearing entities¹.

This represents what Okta identifies as “the identity gap”, a dangerous mismatch between how fast AI agents proliferate and how slowly security controls adapt. While enterprises spent decades refining identity governance for employees, contractors, and partners, AI agents now operate outside these frameworks, accumulating privileged access without oversight, accountability, or audit trails.

The problem intensifies with “shadow AI”, agents employees create informally through platforms like ChatGPT Team, Claude for Work, or custom scripts calling LLM APIs. Research shows 91% of organizations already deploy AI agents, yet 44% lack governance frameworks and 23% have experienced credential exposure through agents². These aren’t theoretical risks: unauthorized agents have accessed sensitive databases, exfiltrated confidential data, and made unauthorized API calls, all while remaining invisible to security teams.

Against this backdrop, Okta’s Showcase 2026 event on March 16, 2026, delivered a strategic response: the Agentic Enterprise Blueprint, a comprehensive framework positioning AI agents as first-class identities within the enterprise security fabric¹.

The Regulatory Imperative

#

As organizations deploy AI agents at scale, regulators worldwide are establishing governance frameworks. Regulations such as the EU Artificial Intelligence Act, along with emerging standards in the US, UK, and Asia-Pacific, share common requirements that directly intersect with identity management:

• Traceability: Complete audit logs of AI system decisions and actions
• Human Oversight: Mechanisms to pause, override, or revoke agent actions
• Accountability: Clear attribution of who authorized each agent and what it accessed
• Transparency: Users must know when they interact with AI systems
• Cybersecurity: AI systems must be resilient to attacks and unauthorized access

These requirements make AI identity governance a board-level compliance imperative. The Agentic Enterprise Blueprint provides the foundation for meeting these obligations through comprehensive agent discovery, lifecycle governance, and audit-ready accountability.

Okta Showcase 2026: Securing the Agentic Enterprise

#

On March 16, 2026, Okta unveiled a comprehensive platform evolution designed to answer three foundational questions every CISO must address in the agentic era¹:

1. Where are my agents? – Establishing complete visibility across shadow and sanctioned deployments
2. What can they connect to? – Mapping and controlling resource access pathways
3. What can they do? – Enforcing runtime controls and behavioral policies

Major Announcements

#

Okta for AI Agents (General Availability: April 30, 2026) A platform extension bringing AI agents into the enterprise identity security fabric with capabilities spanning discovery, registration, governance, and threat response¹³.

Auth0 for AI Agents (Early Access) Developer-focused tools enabling application teams to build secure agentic workflows with identity verification, token management, and human approval mechanisms²³.

Identity Security Fabric Use Cases (Generally Available) Unified control plane integrating governance, threat protection, and privileged access across human and non-human identities³.

These announcements represent more than feature additions: they constitute an architectural shift treating AI agents as first-class identities alongside employees, contractors, partners, and service accounts.

The Agentic Enterprise Blueprint: A Three-Pillar Framework

#

Okta’s Agentic Enterprise Blueprint provides a structured approach to AI agent security, built on three interconnected pillars that answer the foundational questions every security team must address⁴:

Pillar 1: “Where are my agents?” — Discovery & Visibility

#

The Challenge: Shadow AI proliferates through multiple channels: employees creating custom agents via public LLMs, development teams integrating third-party agent platforms, business units deploying specialized automation tools. Traditional discovery mechanisms fail because agents don’t authenticate like humans.

The Solution: Multi-layered detection combining:

• Agent integrations: Direct registration from agent platforms like Boomi, DataRobot, Google Vertex AI, and custom systems through the Okta Integration Network
• Browser-based protection: Identifying agents created through web interfaces using Okta Browser Plugin analytics
• Endpoint detection: Discovering agents running on managed devices
• Network detection: Identifying unauthorized agent communications through SASE and network monitoring
• Gateway detection: Spotting unregistered AI clients through API gateway traffic pattern analysis
• AI agent risk detection: Automated risk assessment generating risk signals for newly discovered agents

Okta Implementation: Shadow AI Agent Discovery scans cloud environments to automatically detect unmanaged agents, flagging them for security review before registration. This addresses the 91% of organizations already deploying agents, many unknowingly, by making the invisible visible²³.

Pillar 2: “What can they connect to?” — Access Control & Credential Management

#

The Challenge: AI agents require access to databases, APIs, SaaS applications, and other agents to perform their functions. Traditional approaches grant agents static service account credentials, creating permanent privileged access that violates least-privilege principles and presents attractive targets for attackers.

The Solution: Dynamic credential management and centralized authorization covering all connection types:

• MCP servers: Centralized Agent Gateway aggregating access to Model Context Protocol servers for tool and data access
• SaaS services: OAuth/OIDC-based authentication to enterprise applications with scope-based permissions
• Agent-to-agent connections: Cryptographic handshakes and policy enforcement when agents invoke other agents
• Service accounts: Governance and visibility over underlying service account usage
• Vaulted credentials: Secure credential storage with automated rotation eliminating static secrets

Okta Implementation: Universal Directory now treats AI agents as distinct identity types, each with ownership attribution, approval workflows, and access policies. The Agent Gateway (leveraging MCP) provides a unified access layer where security policies apply consistently across all agent interactions³⁴.

This approach directly supports regulatory compliance by eliminating the credential sprawl that makes traceability impossible. With credentials tied to specific agent identities rather than generic service accounts, organizations can definitively answer: “Which agent accessed this data, when, and why?”

Pillar 3: “What can they do?” — Governance & Runtime Controls

#

The Challenge: Without governance, agent permissions accumulate over time, following the same “privilege creep” pattern that plagues human identities. Agents created for temporary projects continue accessing resources indefinitely. Ownership changes occur without access reviews. Test agents migrate to production with excessive permissions.

The Solution: Extending Identity Governance and runtime controls to non-human identities:

• Kill switch: Universal logout capability for instant emergency response
• Runtime enforcement: Policy engine evaluating every agent action against defined rules
• Agent lifecycle management: Certification campaigns, deactivation workflows, and continuous least-privilege assessment
• Human-in-the-loop: Approval workflows pausing agent operations for sensitive actions requiring human oversight
• Audit logs and telemetry: Complete trails capturing agent actions, configuration changes, and compliance evidence

Okta Implementation: Okta Identity Governance (OIG) now includes AI agents in standard certification workflows. Security teams can launch campaigns asking: “Should the Customer Support Agent still access the Payment Database?” Business owners approve, modify, or revoke access, applying the same rigor to agents as to privileged human accounts³.

The Universal Logout capability addresses perhaps the most critical requirement: immediate threat response. If an agent exhibits anomalous behavior, like accessing unusual data volumes, making unexpected API calls, or showing signs of prompt injection compromise, security teams can instantly revoke all access while investigating¹³.

The Three Pillars in Action: An Integrated Architecture

#

The following diagram illustrates how these three pillars interconnect through the Okta platform, with the Agent Gateway and Policy Engine at the center, processing risk signals from discovery, enforcing access policies, and enabling runtime controls including the kill switch for emergency response:

Technical Deep Dive: Okta for AI Agents

#

Okta for AI Agents extends the core identity platform with capabilities specifically designed for autonomous systems³⁴.

Key Capabilities

#

1. AI Agent Registration in Universal Directory

Powered by Okta Universal Directory

Each agent becomes a distinct identity with attributes including:

• Agent name and description
• Owner/sponsor (human accountability)
• Creation date and lifecycle status
• Access permissions and scope
• Connection to underlying service accounts
• Risk score based on privilege level and behavior

This registration process answers regulatory traceability requirements: organizations can demonstrate which agents exist, who authorized them, and what they’re designed to do.

2. Shadow AI Discovery Engine

Powered by Okta Identity Security Posture Management (ISPM)

The discovery engine leverages multiple data sources:

• Cloud infrastructure APIs (scanning AWS, Azure, GCP for agent workloads)
• SaaS application logs (identifying agents authenticated to Salesforce, Microsoft 365, etc.)
• Network traffic analysis (spotting LLM API calls from unexpected sources)
• Endpoint detection (finding agents on developer workstations)

Discovered agents are flagged as “unmanaged” and enter a registration workflow requiring:

• Business justification
• Owner assignment
• Risk assessment
• Access scope definition

3. Privileged Credential Management

Powered by Okta Privileged Access

Rather than granting agents permanent credentials, Okta implements:

• Just-in-time credential provisioning: Generating short-lived tokens only when agents need access
• Automated credential rotation: Rotating underlying secrets without agent code changes
• Secure vaulting: Storing credentials in hardware-backed secure enclaves
• Usage tracking: Complete logs of credential issuance and usage

This eliminates the 23% of organizations experiencing credential exposure through agents, by ensuring credentials are ephemeral, monitored, and revocable².

4. API Access Management Integration

Powered by Okta API Access Management

Okta’s API Access Management enforces least-privilege at runtime:

• Agents receive OAuth 2.0 access tokens scoped to specific resources and operations
• Token introspection validates permissions on each request
• Policy engine evaluates context (time, frequency, data volume) before granting access
• Anomaly detection identifies deviations from expected behavior

For example, a “Customer Support Agent” might have scope: read:customer_data, read:order_history, but explicitly lack write:payment_methods. Attempts to exceed scope are blocked and logged.

5. Certification Workflows & Governance

Powered by Okta Identity Governance (OIG)

AI agents enter the same governance lifecycle as human identities:

• Onboarding: Formal request-and-approval process
• Access reviews: Quarterly certification campaigns
• Lifecycle events: Automated deactivation when owners leave, projects end, or risk thresholds exceed
• Audit reporting: Complete trail for compliance teams

6. Universal Logout / Kill Switch

Powered by Okta Identity Threat Protection (ITP) and Single Sign-On

The emergency response mechanism revokes:

• All active sessions and access tokens
• MCP server connections
• API gateway authorizations
• Privileged credential access

This supports regulatory human oversight requirements: organizations can immediately halt agent operations if harm is detected³.

Demo Video

#

See the Okta for AI Agents demo video showcasing agent discovery, registration, access control, and runtime governance in action:

Identity Fabric for the AI Era

#

The Agentic Enterprise Blueprint extends Okta’s foundational Identity Fabric concept: a unified architecture governing all identity types, to explicitly encompass AI agents³.

This architectural approach delivers strategic advantages:

1. Unified Governance Model

Rather than separate systems for:

• Employees and contractors
• Partners and customers
• Service accounts and applications
• AI agents

Organizations manage all identities through a single control plane. This eliminates governance blind spots and reduces operational complexity.

2. Open Standards Foundation

The Agentic Enterprise Blueprint leverages standards including:

• OAuth 2.0 / OIDC: Authentication and authorization
• SCIM: Identity provisioning
• Model Context Protocol (MCP): Agent-to-resource access
• Shared Signals Framework (SSF): Cross-platform threat intelligence

This vendor-neutral approach prevents lock-in, enabling organizations to choose best-of-breed agent platforms while maintaining consistent security controls.

3. Future-Proof Architecture

As AI capabilities evolve, from today’s task-specific agents to tomorrow’s general-purpose autonomous systems, the identity framework remains constant. New agent types register in Universal Directory, receive scoped permissions, undergo governance reviews, and integrate with threat detection, no architecture redesign required.

4. Business Enablement, Not Obstruction

The blueprint’s goal isn’t blocking AI innovation but enabling it securely. By providing:

• Streamlined agent registration workflows
• Developer-friendly APIs (Auth0 for AI Agents)
• Automated compliance reporting
• Clear approval processes

Organizations can deploy agents confidently, knowing security and compliance are assured from day one.

Conclusions: Treating Agents as First-Class Identities

#

The proliferation of AI agents represents the most significant identity challenge since the rise of SaaS applications a decade ago. Just as organizations eventually standardized on SSO and centralized IAM for cloud applications, the agentic era demands extending identity governance to autonomous systems.

Okta’s Showcase 2026 announcements: Okta for AI Agents, Auth0 for AI Agents, and the Agentic Enterprise Blueprint, which provide the first comprehensive framework treating agents as first-class identities. This isn’t simply a product evolution; it’s an architectural maturation recognizing that identity is the control plane for all enterprise interactions, whether initiated by humans, applications, or AI.

As AI regulations worldwide (such as the EU Artificial Intelligence Act) take effect, organizations face a choice: reactively bolt-on compliance after agents are deployed, or proactively build governance into the foundation. The Agentic Enterprise Blueprint enables the latter, transforming regulatory obligation into strategic advantage.

The key insight is this: AI agents are not tools; they are autonomous actors requiring the same identity rigor as employees accessing sensitive data. Organizations that recognize this fundamental shift (and implement governance accordingly) will navigate the agentic era securely, compliantly, and competitively.

Those that delay face the same credential sprawl, shadow IT proliferation, and audit nightmares that plagued early cloud adoption, except at machine speed, with AI agents autonomously accessing data 24/7/365 without visibility or control.

The identity gap is real. The Agentic Enterprise Blueprint closes it.

Getting Started with AI Agent Governance

#

🎓 Get the Okta for AI Agents Early Adopters badge

#

Become an AI Identity Leader: learn to evaluate AI risks and identity security gaps, and implement a comprehensive governance framework using Okta for AI Agents.

Get your Okta for AI Agents Early Adopters skills badge today!

🚀 Explore Okta’s AI Agent Capabilities

#

• Okta for AI Agents: Learn about discovery, governance, and threat response for enterprise agents
• Auth0 for AI Agents: Explore developer tools for building secure customer-facing agentic applications
• Agentic Enterprise Blueprint: Download the complete framework guide
• Compliance Resources: Understand how identity governance supports regulatory requirements

💬 Join the Conversation

#

How is your organization approaching AI agent security? Have you encountered shadow AI in your environment? What governance challenges keep you up at night?

Share your experience in the comments below or connect with me on LinkedIn to continue the discussion.

The guards in the digital identity era

#

«Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor.» — Decimus Iunius Iuvenalis ¹

«Bolt the door, keep her in, but who will guard the guards themselves? The wife is cunning and will start with them.»

Originally referring to the difficulty of controlling marital infidelity, this famous Latin phrase by Roman poet Juvenal has become a timeless maxim about the nature of power, trust, and vigilance. The question “Quis custodiet ipsos custodes?” — Who will guard the guards themselves? — resonates powerfully today in the world of cybersecurity, prompting us to question who protects the systems that, in turn, protect us.

In an era where the security perimeter is no longer physical but virtual, digital identity has become the new bastion to protect. This brings us to a crucial paradox: can we truly entrust identity management to the same provider that hosts our infrastructure and services?

Recently, a client posed a deliberately provocative question: “What’s the point of Okta? My current provider can already give me everything: infrastructure, email, storage, Business Intelligence, device protection… and even identity management. Why should I spend more money on Okta when I can have everything practically free and integrated with what I already have?” This statement, seemingly logical and innocuous, reveals a widespread perception: that IAM (Identity and Access Management) is a simple integrated feature, not a strategic choice. The debate isn’t between two products, but between a centralized model and an independent, agnostic architecture.

The Zero Trust Model

#

We all know by now that the traditional security model, based on the concept of “trusted perimeter,” is obsolete. In a world where people work remotely, access SaaS resources, and interact with APIs, implicit trust is a vulnerability. The answer to this challenge was initially the Zero Trust model, whose core philosophy is “never trust, always verify.”

Identity as the pillar of security

#

The CISA’s Zero Trust Maturity Model (ZTMM), a globally recognized framework, identifies Identity as the first of the fundamental pillars of this architecture. Identity is not just a component, but the primary control point upon which the entire security strategy is founded. To successfully implement this model, an organization needs a robust IAM system capable of:

• Applying adaptive policies: Dynamically adapting access policies based on context (user, device, location, time).
• Using strong authentication: Implementing intelligent, adaptive, and phishing-resistant multi-factor authentication (MFA).

Tools like FastPass, Adaptive MFA, and Identity Threat Protection (ITP) become essential for achieving these objectives, ensuring that only legitimate users and devices can interact with corporate resources.

The foundations

#

If we then analyze the foundations, we find:

• Governance: defines the rules and policies that guide the entire security strategy. It’s not enough to implement the right tools; it’s crucial to establish who can access what, under what conditions, and for how long. Solutions like Okta Identity Governance become vital in this context, as they ensure that access is always compliant with corporate policies and is revoked in a timely manner when no longer necessary. This approach not only strengthens security but also ensures regulatory compliance.

• Automation and Orchestration: The effectiveness of a Zero Trust model depends on its ability to react quickly to context changes. Manually managing every single access request or every device state change would be impossible. Tools like Okta Workflows allow automation of identity and access management processes, eliminating the need for manual interventions, reducing human errors, and significantly improving operational efficiency. Automation allows the system to adapt in real-time, applying the “never trust, always verify” philosophy in a scalable way.

• Visibility and Analytics: To make informed decisions and react to threats, an organization must have a clear and constant view of what’s happening in its ecosystem. Platforms like Okta ISPM (Identity Security Posture Management) are designed to continuously analyze the health of identity security, providing valuable data and insights that help identify and mitigate risks before they can become serious problems. The ability to analyze data and visualize access patterns is the pivot on which the proactive reaction capability of the Zero Trust model is based.

Better together: the other pillars

#

Continuing with the other “pillars”:

• Device: The device represents the first point of contact and a potential vulnerability. Integration of IAM with Device Management ensures that only trusted devices, compliant with security policies, can access applications and data. Okta leverages standard technologies, such as SCEP (Simple Certificate Enrollment Protocol), to integrate with the most common Device Managers. This protection is further reinforced by integrations with third-party tools like EDR (Endpoint Detection and Response) such as CrowdStrike, which constantly monitor the device’s security status and report anomalies, blocking access in case of detected threats. Additionally, Okta Desktop Access (ODA) allows implementing multi-factor authentication directly from the desktop, blocking operating system access.

• Networks: The traditional network perimeter no longer exists. With cloud adoption and hybrid work, access to resources occurs from uncontrolled networks. Identity-based authentication and authorization extend to tools like VPNs and, more evolved, to ZTA (Zero Trust Architecture) systems, such as Zscaler. This approach ensures that access to specific network resources is not based only on geographic location or network of origin, but on the validity of the user’s identity, their device, and the context of the request.

• Application & Workloads: Applications are the beating heart of business activity and represent a primary target for attackers. Protection of this pillar is based on extending IAM to the applications themselves, ensuring that every access and operation is traceable, verified, and compliant with policies. Single Sign-On (SSO) and Multi-Factor Authentication (MFA) mechanisms for applications are fundamental to reducing the attack surface. Standardization through protocols like SAML and OIDC (OpenID Connect) allows centralizing identity management across all applications, internal and external, and controlling authorizations at a granular level.

ABAC, ReBAC, DLP

#

• Data: The final pillar recognizes that protecting the perimeter isn’t enough: you need to protect the data itself. In this context, IAM evolves from a simple “door guardian” to an intelligent content controller. Through technologies like Attribute-Based Access Control (ABAC) and Fine-Grained Authorization solutions like Okta/Auth0 FGA (and its open version OpenFGA), modern IAM can apply granular authorization policies that go beyond simple authentication. The flexible authorization model of FGA, based on Relationship-Based Access Control (ReBAC), makes it possible to implement data access policies that exactly reflect organizational structure and business processes.

  Integration with DLP (Data Loss Prevention) systems allows blocking non-compliant operations in real-time, while Identity Governance ensures that access rights are automatically revoked when conditions change (role change, contract end, organizational modifications).

Identity Fabric: The Architecture That Unifies Identities

#

While the Zero Trust model clearly defines what to protect and how to approach security, it doesn’t automatically solve the problem of coordination between all involved systems. Without a unifying architecture, there’s a risk of having a theoretically solid but practically fragmented Zero Trust model, where each component operates in isolation.

To overcome the fragmentation of these ecosystems, the concept of Identity Fabric emerges as the most effective architectural approach. Identity Fabric is not a single product, but a comprehensive framework that integrates and orchestrates all disparate IAM systems to function as a single unified system. This approach creates a coherent security “fabric” that extends across the entire corporate IT infrastructure, eliminating silos and security blind spots that emerge from a fragmented Zero Trust implementation.

Okta is designed to serve as the central orchestrator in this Identity Fabric. Thanks to its extensive integration capabilities, Okta connects and manages all identities, applications, and infrastructures (IaaS, on-prem, multi-cloud), regardless of the vendor. This vendor-agnostic approach not only ensures complete visibility and centralized control but also allows applying consistent security policies to all digital entities, human and non-human. In practice, it enables orchestrating identities and access in an agile, scalable, and secure way, adapting to a cloud-first and API-driven reality, bringing Zero Trust principles to a broader and more cohesive implementation level.

IPSIE: The Importance of Open Standards

#

The true strength of an Identity Fabric lies not only in a single vendor’s ability to orchestrate all components but in its intrinsic interoperability based on open standards. This principle is fundamental to ensuring that the architecture remains flexible and that organizations maintain the freedom to choose the best solutions for each specific need, without being tied to a single proprietary ecosystem.

Okta actively supports this philosophy through the adoption of standard protocols like SAML, OIDC, OAuth 2.0, and SCIM, and actively participates in the IPSIE (Identity Provider Security and Integration Ecosystem) initiative of the OpenID Foundation². This project aims to create the first unified security standard for enterprise identities, ensuring that different IAM solutions and other security products can communicate and collaborate without compromising security.

The open standards-based approach means that an organization can, for example, use Okta for Identity Governance while maintaining a different solution for Access Management, or exchange signals with third-party security tools like EDR, Antispam, ZTNA. This flexibility democratizes identity security, allowing each organization to build its own tailored Identity Fabric, combining the best available solutions on the market in a coherent and secure ecosystem.

The Hidden Risk of the Integrated Provider

#

Choosing an IAM solution provided by the same vendor that manages your infrastructure and data in the cloud may seem convenient and economically advantageous, but it presents significant risks. Let’s examine them in detail.

Deep integration with a single provider’s proprietary ecosystem can trap companies in an almost irreversible Vendor Lock-in. Migration becomes a prohibitively expensive and time-consuming process, drastically limiting the flexibility to adopt new technologies or negotiate more advantageous economic conditions.

Moreover, when a provider controls both services and infrastructure and the security mechanism, an intrinsic conflict of interest emerges. Their priorities might not be security or universal interoperability, but deep integration with their own ecosystem. This can lead to compromises, security shortcuts, and ultimately to a lack of transparency and impartiality.

Often, clients discover limitations of integrated solutions only when it’s too late and becomes very expensive to change.

The Advantages of Independent IAM

#

An independent IAM solution, like Okta, is designed to be neutral, interoperable, and modular. Choosing an independent platform offers the following advantages:

• Flexibility and Agility: With an extensive catalog of integrations, a vendor-agnostic solution allows companies to adopt a “best-of-breed” strategy, choosing the best tools for each business function and unifying identity management in a single secure platform. For example, it’s possible to choose solutions from different providers for: Infrastructure (IaaS), Collaboration (email, files, instant messaging), EDR, Antispam, etc.
• Neutrality and Open Standards: Solutions like Okta are based on open standards (OAuth 2.0, OIDC, SAML, SCIM), avoiding proprietary logic. This neutrality favors portability, compliance, and interoperability between different ecosystems. This commitment manifests in the IPSIE initiative, which we discussed earlier.
• No dependency on proprietary logic: This approach completely eliminates any dependency on proprietary logic, ensuring that the system is flexible, interoperable, and future-proof. Independence from binding solutions allows organizations to choose technologies best suited to their needs without being limited by a single vendor’s decisions. This favors innovation and adaptability in a continuously evolving technological landscape.
• Resilience and Enhanced Governance: An independent IAM doesn’t limit itself to login. It offers Identity Governance (IGA) tools to manage identity lifecycle, Privileged Access Management (PAM) to protect sensitive accounts, and Identity Security Posture Management (ISPM) for continuous monitoring.

Okta engages in a continuous process of security improvement through investments in innovation, controls, and transparency. This is realized in the Okta Secure Identity Commitment, a long-term strategic initiative to lead the industry in fighting identity attacks. It articulates around four principles: providing cutting-edge secure products, promoting best practices among customers, continuously strengthening internal corporate infrastructure, and elevating standards across the entire industry (for example with IPSIE).

Tangible ROI and Measurable Benefits

#

The advantages of an Identity Fabric-based IAM approach are not just theoretical. According to a recent study by Forrester Consulting³, organizations implementing Okta Identity Governance achieve a 211% ROI over three years. Benefits include:

• Operational cost reduction: Automation of provisioning and deprovisioning activities with a 75% reduction in time needed to manage user access
• Productivity improvement: Users recover an average of 30 minutes per day thanks to SSO and reduced access friction
• Compliance risk reduction: 60% decrease in time needed for audits and compliance verification
• Breach prevention: The avoided cost of a single breach can far exceed the investment in the entire IAM platform

To explore the specific ROI potential for your organization, Okta provides a dedicated calculator that considers the specific dimensions and characteristics of the company.

IAM Maturity Assessment: Where Do You Stand?

#

Before undertaking transformation, it’s essential to assess the current state. Okta’s IAM maturity model identifies four progressive levels that define how Identity capabilities can contribute to achieving business objectives and organizational value:

1. Fundamental: Manual access management, shared passwords, no centralized visibility
2. Scaling: Basic process automation, SSO and MFA implementation across multiple applications
3. Advanced: Centralized policies, structured Governance, advanced Automation, access monitoring and integration with other systems. Identity integrates with the broader technology stack to improve efficiency for proactive security management, with optimized user experiences
4. Strategic: Identity is strategic: Complete automation, predictive analytics, implemented Zero Trust, AI for insights and recommendations. Identity becomes the primary control plane for access administration and a key element of cybersecurity strategy

Most organizations are between Stage 1 and 2, with significant improvement opportunities through adopting a modern IAM platform.

A Balanced Assessment

#

While the advantages of an Identity Fabric are significant, it’s important to recognize some challenges that organizations might encounter:

• Initial setup complexity: Implementing an independent solution requires more initial planning compared to activating an already integrated feature. However, this initial complexity translates into greater long-term flexibility and control.

• Investment in skills: The IT team must acquire familiarity with integration protocols (SAML, OIDC, SCIM) and IAM best practices. Okta mitigates this challenge through over 8,000 out-of-the-box integrations in the OIN - Okta Integration Network catalog, extensive documentation, free training, and dedicated support during onboarding.

• Additional licensing costs: Unlike “free” integrated solutions, a specialized IAM platform has a licensing cost. However, as demonstrated by ROI data, this investment pays back quickly through operational efficiency and risk reduction.

The key is recognizing that these challenges are temporary and mitigable, while the advantages of an agnostic IAM, based on an Identity Fabric architecture, are structural and lasting.

For small and medium enterprises

#

Even if the integrated approach may seem appealing to reduce initial costs and complexity, experience shows that in the long run it doesn’t pay off, especially in terms of ROI and breach risk. Small businesses are often the most vulnerable targets precisely because they perceive security as a cost rather than an investment.

Okta offers specific solutions for small businesses that make enterprise IAM accessible even to smaller organizations, with a scalable pricing model that grows with the company, allowing you to start with essential functionalities and extend them in the future.

This approach allows SMEs and SMBs to implement enterprise security best practices from the beginning, avoiding costly future migrations and protecting themselves from increasingly sophisticated threats that make no distinction between large and small organizations.

Conclusions: Identity as an Impartial Arbiter

#

In today’s digital landscape, identity is the new security perimeter. The choice of an IAM platform is not merely a technical decision, but a fundamental strategic choice. Relying on a single provider for infrastructure, data, and identity may appear advantageous, but true security is founded on separation of powers, transparency, and freedom of choice.

Adopting an independent IAM solution, configured as a true Identity Fabric, means implementing an architecture that ensures unified and secure identity management. This approach reduces risks, increases flexibility, and fully supports a Zero Trust strategy.

As we quoted at the beginning: “Who will guard the guards themselves?”. IAM must operate as an impartial arbiter, not as a player on the field.

Authentic security derives from separation of powers: those responsible for protection cannot be those who control every aspect of infrastructure and data. An independent IAM architecture is not only more secure but is also intrinsically more resilient, scalable, and free.

As an Okta Solutions Engineer, I see the benefits of this approach daily. This is why I believe Okta represents the best implementation of this philosophy.

✋ Your Experience Matters

#

📊 Assess your current state: Before undertaking any IAM transformation, it’s essential to take stock of the situation. Okta offers a free Secure Identity Discovery Assessment that analyzes your current identity security risks through 12 key questions, providing targeted recommendations from Okta experts. Contact me (or your Okta sales representative) to learn more.

📈 Calculate your ROI: Use the Okta ROI calculator to evaluate specific economic benefits for your organization. On average, Okta customers reduce maintenance and development costs by 60%.

📣 Share your experience in the comments: What’s your approach to IAM solutions? Have you ever faced the dilemma between integrated and independent solutions?

🤝 Discover Identity Fabric: If you’re interested in understanding how it can protect your company, contact me for personalized consultation.

The 2024 Situation

#

The recent report “Supervisory reporting framework for operational or security incidents - Cross-sectional analysis 2024”¹ by Banca d’Italia is not just a statistic, it’s a strategic alarm bell for the entire Italian (and, by extension, European) financial sector. The data is clear and concerning: a 45% increase in reported operational and security incidents, totaling 188 notifications, the highest level ever recorded since 2020.

But the most revealing data emerges from detailed analysis: 65% of all incidents involved an external service provider, a huge leap from 45% in 2023. This, combined with an average service restoration time more than doubled (from 9 to 21 hours), tells us one thing clearly: the traditional security perimeter no longer exists. Risk is fragmented, interconnected, and increasingly resides in the management of identities and privileged access.

The threat landscape is also rapidly evolving. “Noisy” DDoS attacks have collapsed by 75% (from 16 in 2023 to 4 in 2024), making way for more silent and targeted threats like malware (50% of cyber incidents), unauthorized access (45%), and social engineering (22.5%). The objective is no longer just to “bring down” a service, but to infiltrate, steal credentials, and move laterally through the interconnected digital infrastructure.¹

These Italian data reflect a broader European trend. The European Banking Authority (EBA) reports that over 58% of European banks suffered at least one cyberattack in the second half of 2024, with 24% recording at least one successful attack with significant impact². In parallel, ENISA identified 488 publicly reported cyber incidents in the European financial sector between January 2023 and June 2024, with banks as the primary target in 46% of cases³.

In this scenario, regulations like the Digital Operational Resilience Act (DORA) and Network and Information Security (NIS) 2 are not merely bureaucratic burdens, but the logical and necessary response to this new reality. With DORA and NIS2 regulatory deadlines already in effect since January 2025, the urgency to adopt a new defense model is maximum⁴⁵.

The question is no longer if to adopt an identity-based security strategy, but how to build it in a way that is cohesive, scalable, and resilient in the face of increasingly sophisticated threats.

The Strategic Response: Building a Resilient “Identity Fabric”

#

Addressing such diverse threats — internal fragility, targeted external attacks, and supply chain vulnerabilities — with a mosaic of isolated security solutions is a losing strategy. Each tool creates a new silo, increasing operational complexity and leaving dangerous blind spots that attackers can exploit.

The modern answer is a unified platform approach: the Identity Fabric by Okta.

What is an Identity Fabric? Identity Fabric is a unified identity security architecture that supports all identity use cases while being fully orchestrated and integrated. Think of it as an intelligent connective tissue that unifies the security of all identities (employees, customers, partners, APIs, AI agents, and service accounts) and all resources (applications, infrastructure, data). Instead of fragmented silos, it creates a single control plane that offers centralized visibility, policy orchestration, and coordinated threat response.

The Okta Platform represents the natural evolution of this vision, offering an end-to-end solution that brings Identity Fabric to real life. Composed of Okta Workforce Identity and Okta Customer Identity, the platform is designed with this architecture in mind, ensuring that the product ecosystem works together to reduce risk while organizations focus on delivering world-class digital experiences (see One Platform, Every Identity).

A fundamental concept of this approach is technological neutrality, which guarantees the freedom to choose the best technologies without being tied to a single proprietary ecosystem. This is particularly critical in a sector like banking, where integration with legacy systems and third-party providers is essential.

An effective Identity Fabric is founded on four strategic pillars that work in synergy.

1. Beyond MFA: Phishing-Resistant Authentication

#

With social engineering and credential theft as primary attack vectors (responsible for 22.5% of cyber incidents in 2024), traditional MFA (push notifications, OTP) is no longer sufficient. It’s essential to neutralize phishing at the root with phishing-resistant methods.¹

💡 Key Technologies:

• Okta FastPass uses open cryptographic standards like FIDO2 to cryptographically bind authentication to the device. Simply put, even if a user is tricked into entering their credentials on a fake site, these are useless to the attacker because they cannot be reused elsewhere thanks to public key cryptography.
• Okta Adaptive MFA: This solution goes beyond static MFA, offering risk-based dynamic authentication that evaluates the context of each access attempt. The system analyzes factors like geographic location, device used, user behavior, and compromise indicators (such as proxy use or compromised passwords) to automatically determine the required authentication level. For high-risk transactions or access from non-compliant devices, it can require additional factors like WebAuthn or biometrics, while for low-risk scenarios it reduces user friction while maintaining security.

2. Total Governance: Managing the Lifecycle of All Identities

#

The 65% of incidents involving suppliers highlights a critical problem of access governance in the digital supply chain. This risk is amplified by the explosion of Non-Human Identities (NHI) — API keys, service accounts, system tokens, digital certificates — which today far outnumber human ones and are the connective tissue of the digital supply chain. The lack of governance of these identities with the same rigor as human ones represents a direct violation of DORA principles.¹

💡 Key Technologies:

• Okta Identity Governance (OIG) automates the entire access lifecycle through intelligent JML (Joiner-Mover-Leaver) workflows. The system ensures that every identity — human and non-human — is rigorously applied the least privilege principle through traceable request and approval workflows, automated periodic certification campaigns, and automatic de-provisioning when identities are no longer needed. For non-human identities, it implements automatic credential rotation and continuous usage monitoring.
• Okta Privileged Access: This cloud-native PAM solution eliminates permanent access (standing access) to servers, containers, and privileged SaaS applications. It implements the Zero Standing Privileges principle, requiring just-in-time approvals for access to critical resources. It includes a cloud vault for secure management of shared credentials, complete SSH/RDP session recording for compliance, and native integration with Okta Access Requests for multi-step approval workflows with business justification and limited time durations. Particularly important for banks, it also manages privileged access to break-glass identities and critical service accounts.

3. From Prevention to Continuous and Proactive Protection

#

Security cannot be a static control at login time. It must be a dynamic process that evaluates risk in real-time, throughout the session duration, continuously adapting to the evolving threat landscape.

💡 Key Technologies: Two complementary capabilities are needed here that work in synergy to offer 360-degree protection:

• Okta ISPM – Identity Security Posture Management: This is proactive defense. ISPM functions as a continuous “check-up” of your identity infrastructure, constantly scanning cloud systems (Azure AD, AWS, Google Workspace, Salesforce) to identify and correct misconfigurations, MFA gaps, excessive privileges, and security vulnerabilities before they are exploited by attackers. With the introduction of new 2025 capabilities, ISPM now also protects AI agents and non-human identities, automatically discovering service accounts, API keys, and other automated identities that often escape traditional governance.
• Okta ITP – Identity Threat Protection: This is real-time reactive defense. Using open standards like CAEP (Continuous Access Evaluation Protocol) and SSF (Shared Signals Framework) to integrate risk signals from the entire security ecosystem (e.g., from an EDR like CrowdStrike), ITP actively monitors every session after initial login. If it detects an anomaly — like a suspicious IP change, an alert from a device security system, or unusual user behavior — it can automatically intervene by terminating the session, requiring re-authentication, or escalating the incident to the security team.

4. Don’t Forget the Customer: CIAM for Highly Regulated Environments

#

Customer trust represents the most precious asset for every financial institution. Protecting customer accounts from fraud and account takeover requires the same level of rigor applied internally, but with particular attention to the balance between security and user experience. In the banking sector, where every friction can translate to customer abandonment, this balance is particularly delicate.

💡 Key Technologies:

• Auth0 with Highly Regulated Identity (HRI) represents the Financial-Grade Identity solution for sensitive customer operations. HRI is specifically designed to meet the highest security and regulatory compliance standards in the financial sector.

• HRI implements three fundamental security pillars:

  • Strong Customer Authentication (SCA) with Dynamic Linking: HRI implements SCA as defined by PSD2 (Payment Services Directive 2), requiring at least two independent authentication factors. Dynamic Linking cryptographically binds transaction details to the SCA approval process, showing the user exactly what they are approving (e.g., Authorize payment of €1,000 to Giovanni Rossi?) and thus preventing sophisticated fraud through transaction tampering⁶.

  • FAPI 1 Advanced Protocols: HRI is a certified implementation of the Financial-Grade API standard by the OpenID Foundation, which includes⁷:

    • PAR (Pushed Authorization Requests): Moves sensitive transaction parameters from the front-channel (browser) to authenticated back-end calls, preventing interception
    • JAR (JWT-Secured Authorization Request): Protects the integrity of the authorization request through digital signature
    • JWE (JSON Web Encryption): Encrypts access token payload to prevent application data breaches

  • Strengthened Application Authentication: Supports Private Key JWT and mTLS (Mutual TLS) as alternatives to client secrets, eliminating the transmission of secrets over the network. Token Binding ensures that only the application that requested an access token can use it, making tokens useless even if intercepted.

  • Customization and User Experience: Despite rigorous security controls, HRI maintains a smooth user experience through native integration with Auth0 Actions for custom authorization logic and new templates for Universal Login that allow customizing approval screens based on the type and details of the specific transaction (see Okta Blog).

From Regulatory Obligation to Strategic Advantage

#

The data from the Banca d’Italia report¹, supported by European trends documented by EBA² and ENISA³, clearly outline an increasingly complex and interconnected cyber battlefield. With 80% of incidents affecting payment services and 65% involving third-party suppliers, addressing these challenges with a fragmented approach is no longer sustainable or economically efficient.

The implementation of the EU Systemic Cyber Incident Coordination Framework (EU-SCICF) under DORA highlights how even regulators recognize that cyber resilience requires coordination and unified visibility at the systemic level. This same principle applies at the enterprise level: a unified Identity Fabric is needed⁸.

Building an Identity Fabric with the Okta Platform means moving from a fragmented reactive defense posture to one of orchestrated proactive resilience. It means unifying visibility across all identities (human and non-human), automating access governance, and orchestrating threat response on a coherent and scalable platform.

This approach not only allows for effectively responding to the stringent requirements of DORA and NIS2, but transforms security from an operational cost center to a true strategic business enabler. A unified and resilient identity platform not only protects the organization from increasingly sophisticated threats, but simultaneously strengthens customer and partner trust, accelerates onboarding of new digital services, and reduces operational costs through intelligent automation.

In the current landscape, where average restoration time has more than doubled and where threats become increasingly silent and persistent, Identity Fabric is no longer a futuristic option — it’s an immediate strategic necessity for the digital survival of the financial sector.

✋ The Time to Act is Now

#

📊 Assess Your Current Position

#

Operational resilience always starts with an assessment of the current state. We suggest starting with:

• Okta Secure Identity Discovery: A free assessment that analyzes your current identity security risks through 12 targeted questions, providing specific recommendations from Okta experts for the Financial Services sector. Contact me to learn more.

• Okta ROI Calculator: Quantify the economic benefits of an Identity Fabric approach.

🎯 Start Your Identity Fabric

#

You don’t need to revolutionize everything overnight. You can start with a gradual approach:

1. Pilot anti-phishing protection: Implement Okta FastPass on a group of users to test the effectiveness of phishing-resistant authentication
2. Manage human and non-human identities: Use Okta ISPM to map all identities, including service accounts and API keys that often escape traditional controls. 💡 You can use it even if you don’t use Okta as IAM!
3. Protect customers: Experiment with Auth0 HRI to implement PSD2-compliant Strong Customer Authentication while maintaining optimal UX

🚀 Immediate Resources

#

• Okta for Financial Services: Specific solutions for banks and financial institutions
• 5 key DORA requirements: useful infographic on DORA regulation
• A Guide to DORA Compliance with Okta: Okta blog article
• PCI DSS 4.0: What financial service providers need to know about new regulatory requirements

🤝 Let’s Discuss Your Strategy

#

The financial sector has unique challenges that require specialized expertise:

📞 Personalized consultation: As a Solutions Engineer specialized in the Italian market, I can help you define an Identity Fabric roadmap specific to your organization, considering legacy systems, regulatory constraints, and business objectives.

💬 Share your experience: How is your identity security strategy evolving? What are the biggest challenges you face in managing human and non-human identities in the DORA/NIS2 context? Let’s discuss in the comments.

📰 Follow me on LinkedIn for regular insights on Identity Fabric, regulatory compliance, and best practices for the Financial Services sector.

The July 2025 release of the fourth revision of the NIST Digital Identity Guidelines marks a turning point in the evolution of digital security standards. NIST SP 800-63-4¹ is not just a technical update, but a strategic response to emerging threats that have shaped the cybersecurity landscape in recent years, with particular focus on sophisticated phishing and social engineering attacks that have compromised even enterprise organizations with advanced security controls.

The timing of this revision is no coincidence: over the past three years, we have seen an escalation of attacks exploiting weaknesses in traditional multi-factor authentication implementations, proving that SMS OTP and non-cryptographic hardware tokens can be bypassed with increasingly sophisticated man-in-the-middle techniques.

The modular structure

#

The fourth revision maintains the modular approach introduced in version 3, consisting of four distinct volumes addressing complementary aspects of digital identity management²:

• SP 800-63³: The base volume defining the Digital Identity Model, risk management principles, and fundamental terminology
• SP 800-63A⁴: Identity Proofing and Enrollment, covering identity verification and user registration processes
• SP 800-63B⁵: Authentication and Authenticator Management, dedicated to authentication mechanisms and authenticator lifecycle management
• SP 800-63C⁶: Federation and Assertions, defining protocols for federation and assertion management

This article specifically focuses on the base volume and SP 800-63B⁵, which covers authentication and authenticator management, central elements for any modern enterprise IAM strategy.

The importance of these standards extends beyond U.S. borders. In Europe, NIST SP 800-63 serves as a fundamental technical reference inspiring directives such as NIS2 and DORA, providing a pragmatic framework to implement effective security controls. Multinational organizations often use NIST SP 800-63 as a common baseline to standardize security controls across different jurisdictions, significantly simplifying governance and multi-regional compliance.

The convergence between U.S. and European standards is accelerating, with ENISA explicitly referencing NIST for specific technical aspects, creating a global ecosystem of shared best practices⁷.

Why it represents the future of Authentication

#

SP 800-63B defines the technical requirements for user authentication and authenticator lifecycle management, introducing a risk-based approach balancing security and usability through three Authenticator Assurance Levels (AAL)⁸:

• AAL1: Single-factor authentication based on “something you know” (passwords, PINs)
• AAL2: Multi-factor authentication requiring at least two distinct authentication factors
• AAL3: Multi-factor authentication with mandatory phishing resistance

The true innovation lies in the risk-adaptive approach allowing organizations to dynamically adjust authentication controls based on session context, user, and resource sensitivity⁹. This means the same user can experience different authentication requirements depending on a real-time risk score.

The integration of behavioral analytics and threat intelligence in decision-making marks a significant advancement over traditional static controls that applied uniformly regardless of operating context.

AAL Levels and authenticator requirements

#

Evolution from v3 to v4

#

The transition from version 3 to 4 introduces paradigm shifts reflecting evolving threat landscapes and technological progress. A comparative analysis highlights most important transformation areas:

Key innovations

#

Beyond the comparative framework, NIST SP 800-63-4 introduces fundamental innovations that redefine enterprise authentication. Here’s how these changes translate to real-world implementations.

Digital Identity Risk Management (DIRM)

#

NIST SP 800-63-4 introduces the revolutionary concept of “continuous evaluation”¹⁰ in identity risk management, transforming security posture from reactive to predictive through continuous intelligence.

The framework sets specific requirements for continuous evaluation¹⁵:

• Real-time risk scoring based on behavioral analytics
• Threat intelligence integration identifying compromise indicators
• Adaptive authentication controls dynamically adjusting requirements
• Comprehensive audit trails for forensics and compliance

To operationalize this vision, NIST defines a structured five-step DIRM process ensuring continuous, risk-based control of digital identity:

1. Define the Online Service Document service scope, user groups, and assets to establish context for risk analysis.
2. Assess Service-Level Risks Identify risks arising from the online service itself — data sensitivity, threat landscape, and potential impacts.
3. Assess Identity-System Risks Evaluate risks introduced by the identity solution — fraud vectors, privacy concerns, and usability factors.
4. Select and Tailor Controls Choose baseline controls (IAL/AAL/FAL) and tailor them via compensating or supplemental measures based on your risk assessments.
5. Monitor and Reassess Continuously Execute continuous evaluation, update risk assessments, and adjust controls as threats and service requirements evolve.

Okta’s integrated platform directly supports this NIST framework through two complementary solutions that - in addition to well-know features like SSO and Adaptive MFA - address the DIRM process:

• Okta Identity Security Posture Management provides continuous monitoring via:
  • 360-degree identity visibility across cloud, on-premises, and hybrid environments
  • Risk scoring algorithms considering over 200 identity risk factors
  • Automated remediation workflows for immediate threat response
  • Compliance automation maintaining posture alignment with multiple frameworks
• Okta Identity Threat Protection delivers detection and response intelligence via:
  • Machine learning models trained on global threat intelligence
  • Behavioral baselines for each user-device combination
  • Real-time threat blocking for known malicious IPs and patterns
  • Investigation workflows supporting security teams

Integration of ISPM and ITP creates a closed-loop security system identifying risks, implementing compensating controls, and verifying mitigation effectiveness in real time — precisely the outcome NIST SP 800-63-4 envisions for modern Digital Identity Risk Management (DIRM).

The end of password expiration

#

NIST SP 800-63-4 definitively ends the era of passwords expiring every 90 days¹¹, based on a decade of behavioral research showing such practices adversely affect security.

Studies cited by NIST demonstrate forced password expiration systematically leads to:

• Predictable incremental patterns (password123, password124, etc.)
• Cross-system reuse to reduce cognitive load
• Voluntary weakening of passwords to ease memorization
• Shadow IT behaviors like writing down passwords in insecure locations, or non-approved Password Managers

The modern approach favors complex yet stable passwords, supported by continuous monitoring systems that identify compromise indicators without requiring arbitrary rotation¹⁶.

This paradigm shift aligns perfectly with Okta’s strategy, where Okta Identity Security Posture Management continuously provides visibility into credential-related risks through:

• Breach database correlation for compromised password detection
• Weakness analysis based on entropy and pattern recognition
• Usage analytics for identifying dormant accounts or login anomalies
• Automated compliance reporting for audit and governance

Okta and Auth0 further strengthen this approach through Breached Password Detection capabilities, automatically scanning credentials against comprehensive databases of compromised passwords, eliminating the need for arbitrary password rotation while maintaining robust security posture.

Phishing-Resistant Authentication

#

One of the most significant revolution is the mandatory introduction of phishing-resistant options for AAL2¹², a direct response to attacks showing traditional controls’ ineffectiveness against sophisticated phishing campaigns.

Phishing-resistant authenticators rely on cryptographic proof of origin that mathematically binds authentication to the application’s specific domain. This entails:

• Origin binding through TLS channel attestation
• Public-key challenge-response protocols
• Replay protection via cryptographic nonces
• Device attestation to verify authenticator integrity

Okta FastPass is the most advanced market implementation of this paradigm in the enterprise. Built on FIDO2/WebAuthn principles but extended across the Okta app ecosystem, FastPass features:

• Device-bound cryptographic keys generated and stored in hardware security modules
• Automatic origin verification preventing man-in-the-middle attacks
• Transparent fallback mechanisms for legacy applications
• Centralized policy management for scalable deployment¹⁷

Native integration with the Okta ecosystem means FastPass works immediately with thousands of SaaS applications without app modifications — a competitive advantage over traditional FIDO2 implementations needing per-app integration.

Syncable Authenticators / Passkeys

#

NIST SP 800-63-4 explicitly introduces support for “Syncable Authenticators”¹³, an innovative category solving the portability problem of cryptographic credentials across multiple devices while maintaining high security standards.

Specific requirements for syncable authenticators include¹⁸:

• End-to-end encryption during synchronization
• Device attestation for every endpoint accessing keys
• Secure key derivation preventing key extraction
• Audit logging to track synchronization events

Passkeys represent the most mature implementation of this concept, combining FIDO2/WebAuthn security with cloud-based syncing managed by platforms (iCloud Keychain, Google Password Manager, Microsoft Authenticator).

Okta offers the most comprehensive enterprise passkey support on the IAM market, featuring:

• Cross-platform registration flows adapting automatically to device capabilities
• Intelligent fallback chains guiding users to the most secure available authenticator
• Enterprise policy controls governing passkey usage in business contexts
• Analytics and adoption tracking to measure deployment success¹⁹

Okta manages user experience complexities automatically, such as handling access from unsynced devices and migrating users gradually from legacy authenticators.

Connected Authenticators

#

“Connected Authenticators” represent the natural evolution of traditional hardware tokens, encompassing devices connecting via USB, NFC, or Bluetooth but implementing modern cryptographic protocols²⁰.

NIST SP 800-63-4 recognizes these devices as the gold standard for AAL3, especially in high-risk contexts where physical authenticator separation is critical. Benefits include:

• Hardware-based key storage preventing key extraction even after device compromise
• Tamper resistance certified under FIPS 140-2 Level 2+
• Multi-protocol support for legacy and modern application compatibility
• Enterprise management capabilities for bulk provisioning and lifecycle management

Okta’s connected authenticator integration is native and comprehensive, covering the entire available hardware security key ecosystem, with particular excellence in YubiKey support:

YubiKey Example

#

Okta provides the market’s most advanced support for Yubico YubiKey devices, managing the full lifecycle with enterprise-grade features:

• Pre-enrollment & distribution
  • Centralized bulk provisioning of hundreds/thousands of YubiKeys
  • Secure direct-to-employee shipping with verifiable chain of custody
  • Automatic activation on receipt, no IT intervention
  • Custom packaging with corporate branding
• Lifecycle management
  • Automated inventory tracking and usage monitoring
  • Backup policies requiring multiple keys per critical user
  • Automated replacement workflows for lost/damaged devices
  • Compliance reporting for audit trails
• Technical integration
  • Full FIDO2/WebAuthn support across all YubiKey models
  • PIV/smart-card compatibility for government use cases
  • Legacy OTP modes for older applications
  • Mobile NFC authentication
• User experience
  • Guided setup wizard and automated troubleshooting
  • Certified multi-browser support
  • Offline authentication capability

Okta’s approach transforms a traditionally complex and labor-intensive process into an automated, scalable experience, significantly reducing deployment costs and improving user adoption.

Biometrics Delegation: pragmatism in Platform Trust

#

Rather than mandating detailed biometric standards, NIST SP 800-63B focuses on accuracy, privacy, and liveness detection requirements, allowing organizations to leverage proven platform-level implementations²¹:

• Apple Secure Enclave for on-device fingerprint/Face ID processing²²
• Windows Hello with TPM-backed anti-spoofing²³
• Android StrongBox for isolated biometric template storage²⁴
• Samsung Knox for hardware-backed biometric verification²⁵

This pragmatic approach lets enterprises benefit from the billions invested by platform vendors in biometric security, rather than reinventing complex systems in-house.

Okta Verify leverages this evolution, providing seamless integration with all major platform authenticators, ensuring optimal user experience without compromising security. Features include:

• Automatic platform detection for optimal authenticator selection
• Progressive enhancement using available biometric capabilities
• Fallback mechanisms for devices without biometric support
• Policy controls governing biometric use per security level

SMS OTP Deprecation

#

The decision to further restrict the use of SMS and voice OTP¹⁴ responds to concrete evidence of compromise. SIM swapping attacks have exploded globally, with the UK experiencing a staggering 1,055% surge in unauthorized SIM swaps in 2024 according to Cifas, rising from just 289 cases in 2023 to almost 3,000 cases²⁶. Meanwhile, SS7-based exploits continue to enable real-time SMS interception²⁷.

NIST SP 800-63-4 specifies SMS OTP can only be used if:

• The organization implements real-time anti-fraud monitoring
• A documented risk assessment process is in place for each deployment
• Compensating controls mitigate known vulnerabilities

These requirements make SMS OTP deployment so complex that it’s practically inadvisable for most enterprise organizations.

Implementation Challenges

#

Adopting NIST SP 800-63-4 involves complexities requiring strategic planning and disciplined execution. The three main challenge areas include:

1. Legacy Application Modernization - Most enterprise applications lack native support for modern authentication protocols. Migration strategy should consider:
   • Implementing identity gateways to wrap legacy authentication flows - solutions like Okta Access Gateway provide seamless integration with legacy applications without requiring code modifications
   • Progressive enhancement gradually introducing phishing resistance
   • User education campaigns for smooth transitions to new methods
   • Risk assessment frameworks for prioritizing application migration
2. Organizational Change Management - Transitioning to passwordless and phishing-resistant authentication requires cultural transformation beyond technology adoption:
   • Executive sponsorship to drive organization-wide adoption
   • Training programs for IT staff on new protocols and troubleshooting
   • Scalable user support to manage increased help desk volume during migration
   • Defining success metrics to measure adoption and security improvements
3. Compliance Orchestration - Multi-jurisdictional organizations must orchestrate compliance requirements across frameworks:
   • Mapping NIST SP 800-63-4 controls to regional requirements (NIS2, DORA, etc.)
   • Automating evidence collection for audit preparation
   • Policy harmonization to avoid conflicting requirements
   • Vendor assessment processes ensuring solution compliance

The role of Integrated Platforms

#

Fragmented implementation of NIST SP 800-63-4 requirements across multiple vendors introduces operational complexity and security gaps potentially compromising the entire security strategy.

Gartner research shows organizations with more than five identity vendors spend 40% of their security budget on integration and maintenance, leaving insufficient resources for innovation and threat response²⁸.

The strategic response is a unified platform approach managing the entire digital identity lifecycle through:

• Single pane of glass management reducing operational overhead
• Native protocol integration eliminating custom development
• Unified analytics and reporting for complete security posture visibility
• Scalable deployment models supporting organizational growth

The Okta ecosystem delivers this integration via:

• Okta Workforce Identity:
• Auth0
• Okta FastPass
• Native passkey support
• Okta Identity Security Posture Management (ISPM)
• Okta Identity Threat Protection (ITP)

These solutions embody Okta’s **Secure Identity Commitment**m — delivering market-leading products and services, championing customer best practices, and fostering an open identity community that continuously advances security standards.

Business Impact

#

Implementing NIST SP 800-63-4 through integrated platforms delivers measurable ROI across multiple vectors:

• Security ROI
  • Breach prevention: The 2024 Verizon Data Breach Investigations Report shows that 68% of breaches involve the human element, with credential-based attacks being the most common vector²⁹
  • Incident response reduction: Automated threat detection significantly reduces investigation and response times according to industry studies³⁰
  • Compliance automation: Organizations report substantial reductions in audit preparation time with automated evidence collection³¹
• Operational ROI
  • Help desk reduction: Gartner research indicates that 20-50% of help desk calls are password-related, with each reset costing organizations $70 on average³²
  • Provisioning automation: Forrester research shows enterprise identity platforms can save organizations significant operational costs through automation³³
  • Vendor consolidation: Multiple identity vendors create operational overhead and integration complexity³⁴
• User Experience ROI
  • Productivity improvement: Studies show employees spend approximately 11 hours annually managing passwords and authentication³⁵
  • Mobile experience optimization: Native platform authenticators reduce authentication friction
  • Adoption acceleration: Okta customer studies demonstrate improved user satisfaction with modern authentication methods³⁶

Preparing for the future

#

NIST SP 800-63-4 lays the foundation for future security evolutions, with emerging trends shaping the next generation:

• Quantum-Resistant Cryptography or Post-Quantum cryptography (PQC) While NIST SP 800-63-4 emphasizes cryptographic agility, organizations should note that NIST is actively preparing for post-quantum cryptography transitions through separate initiatives, with implementation expected by 2030³⁷.
  Okta Ventures has identified post-quantum cryptography as one of five key focus areas for 2025, actively seeking innovative companies with unique approaches to future-proof identity infrastructure against quantum threats. Recent breakthroughs from leading quantum computing research have accelerated timelines, making post-quantum readiness more urgent than previously anticipated³⁸.
• Decentralized Identity Models
  Verifiable credentials and blockchain-based identity represent the move toward user-controlled identity, with NIST developing specific guidance for these paradigms³⁹. Both Okta and Auth0 actively participate in the Decentralized Identity Foundation, contributing to standards development for self-sovereign identity solutions.
• Protocol Security Evolution: IPSIE
  The Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) initiative represents the maturation of OAuth 2.0 and OpenID Connect for enterprise use. As organizations implement NIST SP 800-63-4’s authentication requirements, IPSIE provides critical guidance for secure federation protocol implementation, eliminating common vulnerabilities while ensuring cross-vendor interoperability.

AI-Powered Adaptive Authentication

#

NIST SP 800-63-4 formally acknowledges the role of artificial intelligence and machine learning in modern identity systems⁴⁰, particularly in Section 3.8 which addresses the opportunities and risks of AI/ML integration. The guidelines emphasize that AI systems should enhance rather than replace traditional security controls, while ensuring transparency and accountability in automated decision-making processes.

The NIST framework specifically calls for organizations to:

• Implement explainable AI models that can provide clear rationale for authentication decisions
• Establish human oversight mechanisms for high-risk automated decisions
• Continuously validate AI model performance against evolving threat patterns
• Ensure fairness and avoid bias in AI-driven risk assessments

This guidance aligns perfectly with Okta ITP - Identity Threat Protection with Okta AI, which exemplifies enterprise-grade AI implementation for identity security. ITP leverages machine learning models trained on Okta’s global threat intelligence network, analyzing over 2.5 billion authentication events daily to provide:

• Behavioral baseline establishment for each user-device combination
• Real-time risk scoring based on contextual anomalies and threat indicators
• Automated threat response with configurable policies for different risk levels
• Explainable security decisions through detailed risk factor breakdowns for security teams

The integration of NIST’s AI governance principles with Okta’s practical implementation demonstrates how organizations can leverage AI to enhance security while maintaining the transparency and accountability requirements outlined in the federal guidelines.

Conclusions

#

NIST SP 800-63-4 represents the definitive maturation of the zero-trust paradigm for identity management, consolidating decades of technological evolution and threat intelligence. The abandonment of legacy practices like forced password expiration, combined with emphasis on phishing-resistant authentication and continuous risk evaluation, sets the new global standard for digital security.

Organizations adopting these principles proactively not only markedly mitigate cyber risk but position themselves strategically to capitalize on digital transformation opportunities by enabling secure and frictionless user experiences that support business agility.

Key insight for executive leadership is that implementing NIST SP 800-63-4 is no longer a nice-to-have but a business imperative. Organizations delaying this transition risk:

• Regulatory compliance gaps with emerging frameworks
• Competitive disadvantages in user experience
• Increased likelihood of security breaches with associated financial and reputational costs

For organizations ready to begin their NIST SP 800-63-4 implementation journey, Okta provides comprehensive resources and proven solutions to transform compliance requirements into competitive advantages.

The next article in this series will dive into SP 800-63A (Identity Proofing) and SP 800-63C (Federation), exploring how NIST SP 800-63-4 redefines identity verification and federation management in multi-cloud, multi-vendor environments, focusing particularly on remote identity proofing requirements and cross-domain assertion management.

Have questions about implementing NIST SP 800-63-4 in your organization? I’d love to hear your thoughts and discuss how these innovations can transform your identity security strategy. Feel free to reach out through the comments or connect with me directly.