Last summer, I spent quite a bit of time going deeper into how the Identity Governance and Administration (IGA) world has evolved since the days I was immersed in it, back in the Thoracle days. It’s not like I wasn’t aware of what had been happening. I watched IAM evolve into IGA, and saw PAM, Zero Trust, and ITDR emerge as platforms and buzzwords. So when I was looking at the identity market in the summer, the question I found myself asking was: Is Identity Observability actually something new, or just IGA repackaged? Looking back, I probably went into this assuming it was mostly marketing. After spending time digging in, and working with my friends at ObserveID, I realized that there is something real here. Something that addresses a gap many identity teams feel but struggle to articulate.

The Limits of the IGA Mental Model

IGA is fundamentally about control. It models identities and entitlements, enforces lifecycle processes, certifies access, and produces evidence for auditors. Simply put, IGA aims to answer questions like:

• Who should have access to what?
• How did they get it?
• Who approved it?
• Does this comply with policy?

But, importantly, these questions assume that the identity system is working as designed.

Anyone who has operated IGA in the real world knows that’s often not the case. Most identity failures don’t come from missing policies. They come from:

• Broken joiner/mover/leaver flows
• Stale or incorrect attributes
• Orphaned accounts
• Shadow admins and service accounts
• Failed deprovisioning
• Controls that “exist” but don’t actually fire

Traditional IGA is very good at describing and executing the intended state of identity. Where it falls short is when an organization wants to continuously validate the actual state. That gap is where Identity Observability shows up.

What Identity Observability Actually Is

Identity observability applies observability principles – telemetry, events, metrics, correlation – to identity systems. Instead of just asking:

“Who has access?”

It asks:

“What is actually happening across our identity stack right now, and does it match what we think is happening?”

Conceptually, it’s an operational analytics and assurance layer for identity. It goes beyond configuration to look at runtime behavior. It evaluates data quality and control drift, and surfaces rare or risky access paths. Most importantly, it explains why identity decisions occurred. In other words, the essential outcome here is explainability.

This clicked into place for me when I realized that this wasn’t some new invention. Identity was just catching up to a shift that had already been happening across IT. Infrastructure and application teams, cloud platforms, security operations – each of these domains had shifted from monitoring to observability, reflecting a realization that configuration visibility, static dashboards, and periodic reports just aren’t enough. Systems have become too distributed, too dynamic, and too interconnected. Observability became necessary because modern systems required continuous validation of behavior, not just confirmation of design.

Identity is just going through that same transition.

From Defining Intent to Validating Reality

IGA is a control and workflow plane, focused on policies, roles, lifecycle workflows, certifications, and compliance artifacts. Identity observability, on the other hand, is an assurance and insight plane, focused on whether those controls actually work, where identity data drifts, how access is really being used, and when behavior diverges from intent.

Put simply, IGA defines what should be true, whereas identity observability validates what is true.

The key learning for me was that Identity Observability wasn’t just next gen IGA. It’s a layer that sits above heterogeneous IAM, IGA, PAM, and CIEM tools to make their behavior visible and explainable.

And this is more important than ever. In modern enterprises, identity isn’t static, necessitating a shift from periodic governance to Continuous Identity: continuously validated, continuously explainable, continuously defensible. Modern identity environments have changed dramatically as well. They are multi-cloud, SaaS-heavy, API-driven, full of non-human identities (another term I have been trying to get used to), and owned by many teams. Just like applications and infrastructure before them, identity systems have become distributed systems. And distributed systems require observability.

This makes it almost impossible for organizations to rely solely on a single, centralized control plane to continuously answer the question:

“Is the entire identity fabric behaving as intended, end to end?”

As identity sprawl increases, that question becomes unavoidable. Identity observability introduces a meta-layer that enables identity teams to take this challenge on by:

• correlating signals across identity systems
• detecting gaps between design and reality
• compressing time to insight (crucial to the “continuous” element)
• making identity decisions defensible

So, if you’ve ever been surprised by an audit finding, discovered access paths you didn’t model, found entitlements no one remembered granting, learned a control existed but wasn’t enforced, or spent weeks investigating a “simple” identity issue, then you already understand the problem identity observability is trying to solve. For years, we’ve focused on building IGA systems that can enforce rules. Now we’re realizing we also need systems that can explain behavior.

Because, as the headline said, you can’t secure what you can’t explain.

With this update, users on Windows 11 can now leverage third-party credential managers (not just Microsoft’s own). This is similar to how you can currently use third-party credential managers on your iPhone or Android phone. The third-party credential managers supported at launch are 1Password and Bitwarden, with the promise of more to come.

By integrating directly into Windows, passkey operations (creation, sign-in, management) in these credential managers can leverage Windows Hello, the same user verification and key protection framework leveraged by Microsoft’s own passkey authenticator. This means that any passkey stored with the credential manager of the user’s choice benefits from the same device-based security architecture of Windows Hello: a strong authentication model based on a local device PIN or biometric (face or fingerprint recognition) that is secured by the Trusted Platform Module (TPM). Significantly, all passkeys in the credential manager are accessible in both browsers and native desktop applications, not just web contexts, providing the consistent experience you might be used to on your iOS or Android device.

With this update, Windows 11 is treating passkeys as first-class credentials, managed by users’ preferred tools, but secured by device-level security controls everywhere they’re used.

More Interoperability, Less Friction

Providing individuals and enterprises choice and flexibility in credential managers — so users aren’t limited in how to manage their passkeys, or forced to set up and manage different passkeys for different platforms — is an important element in the plan to make passkeys ubiquitous. All of us working to make passwordless happen do understand that not everyone wants to (or can) use the platform credential manager. By enabling third-party credential managers, the platforms (like Microsoft here) empower users and organizations to adopt passkeys on their own terms, while preserving strong security through their built-in security frameworks (in the case of this Microsoft announcement, this refers to the Windows Hello framework).

Because passkeys now work in native apps too (not just web), and sync across devices, Windows users can enjoy consistent, fast, and secure sign-in everywhere. That reduces friction, improves user experience, and drives broader adoption. That’s a big deal for both consumer and enterprise deployments.

The Hidden Win to Help End Password Pain

What may not be obvious on the surface is how the flexibility this update introduces helps push us towards a truly passwordless future. Supporting third-party credential managers as first-class citizens is particularly important to the cross device and cross platform use of passkeys.

One of the most common reasons people give for their hesitance in setting up a passkey when prompted (usually on their mobile phone) has been “how will I use this on my laptop?”. Of course, FIDO Cross Device Authentication can be used to securely address this scenario. But when synced passkeys were introduced, it gave a significant boost to passkey adoption because having the passkey just show up on your other devices ready to use, instead of having to go through the cross device sign-in flow, was a much smoother experience.

Of course, having a Windows desktop/laptop combined with an iOS/Android phone is the most common setup for many folks, both at home and in the workplace. That’s why this update in Windows 11 is so great, because it makes the power of synced passkeys available to a much bigger proportion of global sign-ins. People with this setup can now use the same credential manager on all their devices, regardless of platform, making their passkey usage seamless across all their everyday devices. Enterprises can deploy the managed credential manager of their choice for their workforce, with the promise of simpler management and smoother multi-platform experience made real. And everyone can still benefit from phishing-resistant cross device authentication for those once-in-a-while situations like logging in on a friend or family member’s device, on shared terminals, or at a public kiosk.

Moving Toward a Passwordless World, Together

With this architectural pattern of building passkey support deep into the OS and extending it to third-party credential managers taking hold in the different platforms, it reinforces FIDO’s role in the identity fabric of the web and enterprise alike. For identity architects and security teams, this update makes it more feasible and cost-effective to plan migrations away from passwords, and achieve a world of fewer support tickets, fewer phishing incidents, and stronger compliance posture. More importantly, this update brings together security, usability, flexibility, and open standards in a package that benefits users, organizations, developers, and the broader identity ecosystem.

All in all, I think it’s safe to say that Windows 11’s new pluggable credential manager support is another compelling signal that the ecosystem is ready and primed to unlock passkeys for real-world scale.

That’s why I’m proud to share that the FIDO Alliance has launched a new Digital Credentials Initiative — a major step toward a future where digital identity wallets and verifiable credentials are as seamless, trusted, and interoperable as passkeys are becoming. In collaboration with our members and partners, we’re building a trusted ecosystem of digital credentials that can be managed by secure wallets, verified across platforms, and used both online and in person for a wide range of real-world scenarios. All while keeping security, privacy, and usability at the center.

As digital ecosystems continue to converge — across payments, health, travel, identity, and enterprise access — having a standards-based, interoperable identity infrastructure is no longer optional. It’s foundational. The opportunity to help shape the digital identity infrastructure of the next decade is exactly what excited me about joining the FIDO Alliance, and launching the new Digital Credentials Working Group with our members is just the first of many steps we’ll take as we advance our expanded mission.

Explore what this means and how to get involved here. Come join the fun.

If you’ve followed my conference talks and blog posts, you know I care deeply about one simple idea: security should make people feel safer and let them get on with their lives. The FIDO Alliance has been driven by that mission for years, with passkeys being the result of that drive – phishing-resistant authentication that is user-friendly and now broadly available across platforms.

But the road from specifications to success has two lanes: adoption at scale and alignment with the rules of the road. Adoption means helping implementers make the right choices, smoothing out the rough edges of real deployments, and proving interoperability through strong certification programs. Alignment means working with policymakers and regulators so that what’s good security practice is also recognized in frameworks and guidance around the world. Both require patient, collaborative work. That’s a big part of why I’m here, and what I find exciting and motivating about taking on this new challenge.

My role at FIDO will be to help our membership guide the Alliance’s technical strategy, keep our specifications coherent and practical, and make sure they tie cleanly to certification and interoperability so relying parties can trust what they’re deploying. It also means rolling up sleeves with our members, other standards bodies, and the public sector to ensure FIDO technology fits naturally into the broader digital trust fabric.

That fabric itself is evolving quite rapidly. Authentication doesn’t live in a vacuum; it connects to how identities are verified, how credentials are carried, and how transactions move. As the ecosystem matures, we’ll continue doing what the FIDO Alliance has always done best: focus on pragmatic, widely adoptable building blocks that make it harder to phish people, harder to steal value, and easier for legitimate users to get things done. This will necessarily touch adjacent areas – identity verification, wallets, payments flows – where clear interfaces and strong assurances help reduce breach and fraud. The point isn’t to broaden the mission for its own sake, but to finish the mission we started: making the online world safer and simpler for everyone.

[Two of the best people in identity, and the world. And me]

I’m on my way to SF to join many, many others in celebrating the life of handsome debonair man about town (self-attested) Andrew Nash. It’s taken me a few days to find the words to write this post. Not because I couldn’t talk about Andrew for hours and hours and hours (that’s called foreshadowing, kids). It’s because anything I can write feels inadequate. Inadequate to capture the generous soul that he was. Inadequate to capture the brilliance of his intellect. Inadequate to capture just how wonderful of a friend he was. But, most of all, completely inadequate to capture just how big of a loss it is that we will no longer have this legend amongst us, that I will no longer get to hear him say “I am just so badly misunderstood”, as he gives that big grin of his.

I have no use for people who have learned the limits of the possible.

― Terry Pratchett, The Last Hero

Hearing me describe him as a legend, his automatic retort would probably have been a good humored and self deprecating “And don’t you forget it”. If you’ve ever had the chance to watch him give a warm smile and laugh a “why, thank you” while glancing down at the ground when you gave him a compliment, you know just how down-to-earth this giant of our industry was. His contributions to security and identity are immense and have shaped our online world in so many ways. He always operated at the leading edge of things to come, whether it be PKI or API Gateways, Identity Verification or Payments, SAML and WS-* or Shared Signals.

[Andrew was frequently my white rabbit]

Frankly (and I told him this many times), it was slightly annoying when you’d tell him about some really cool tech you came across or a fascinating idea you had, and he’d pull out the old “well, it was probably a few years ago that ….” or (even worse) “so we looked at that a while ago, and here’s all the issues you’re about to run into”. His knowledge was vast, and he had this innate ability to cut through the fluff and analyze a problem, an idea, or a technology quickly and comprehensively. He was the best sounding board you could ever find, and it almost felt like he knew exactly what to say to set you on the best possible path forward.

Goodness is about what you do. Not who you pray to.

― Terry Pratchett, Snuff

In many ways, that’s where his biggest and most invisible contribution to our tech industry is. So many of us are doing what we do because of how he helped shape our thinking and our careers in ways both big and small. If you ever needed counsel of any kind, he was there for you, happy to share his wisdom from decades as an entrepreneur, technologist, executive, thinker, tinkerer. He and Pam were the uber-connectors of the identity world, and so many business and work relationships were born at their annual Bootstrap gathering, when they would so generously open their home and go out out of their way to bring people in, making them feel at ease in a room full of strangers. It didn’t matter if you were new to identity, or had been doing this thing for decades. In that loud, boisterous, and seemingly never-to-be-finished house, you knew you were a part of something bigger, and that you belonged.

It’s not worth doing something unless someone, somewhere, would much rather you weren’t doing it.

― Terry Pratchett, in the foreword to The Ultimate Encyclopedia of Fantasy, by David Pringle

We had been friends for a few years when he asked me if I wanted to join him on the RSA Conference program committee, curating the identity track. I don’t know why he decided to ask me, but he will never know the kind of confidence boost it was to have him place that faith in me. He’d been doing it for so many years that he could probably do it in his sleep. But to him, it was a solemn responsibility – to the conference attendees, the speakers, and the industry; one that demanded that we make our very best effort at creating a track that was impactful and valuable, that we were proud of. The hours we’d spend arguing over some of the submissions were some of the most fun and intellectually stimulating debates I’ve been part of. Getting to work with such a brilliant man was incredibly rewarding. Getting to work with my friend was an absolute joy.

It’s still magic even if you know how it’s done.

― Terry Pratchett, A Hat Full of Sky

You’d think that for someone who had accomplished so much, and was involved in so many things, he’d have no time for anything else. Yet somehow, in between pulling PayPal and Google full-fledged into the identity space, laying the foundation for Shared Signals and running a startup at Confyrm, and managing to incubate an identity business within CapitalOne, Andrew found time with Pam to painstakingly and lovingly renovate their SF Victorian themselves, set up an incredible basement workshop that was the envy of those he’d give endless tours to, trained to do precision machining….and so much more. Like so many of the best minds, he had an insatiable curiosity about everything, the drive to dig into anything, and the patience to take everyone along with him on his adventures.

[Part of what lurks beneath the floors that Andrew and Pam laid down]

You may have heard of his passion project to create a replica of the Enigma machine. But nothing about Andrew was an enigma. He was incredibly kind. He was funny and witty. He was an intellectual giant, the closest thing I have ever encountered to a Renaissance Man. He was my friend. He was family. He was taken from us way too soon.

[The last time I saw him, at this years Bootstrap. F Cancer!]

It is said that the hardest part of losing someone isn’t having to say goodbye but rather learning to live without them. Well, once again, Andrew was the teacher extraordinaire, because he taught us all how to live – fully, ridiculously happy, and dedicated to making an impact on the lives of others. I will try my best to follow your example, my friend.

<Slight aside>On LinkedIn, Mike Schwartz called me out for saying we don’t need innovation, which is fair. He pointed out that what I was calling out was not needing more invention (of new tech or standards), but innovating on just getting people to use a lot of what we already have. Thankfully, that lines up with where the rest of this post is going<End aside>

The answer, unfortunately, is as straightforward as it is challenging: the incentives are all wrong.

Secure-by-design isn’t failing because the right standards, technology, or architectures don’t exist. It’s failing because there is no systemic reason to prioritize it – neither for the people building software, nor for those buying it. In fact, one could argue that today’s ecosystem actually discourages secure-by-design thinking. Vendors end up optimizing for roadmap velocity, not resilience. Enterprise buyers meanwhile are optimizing for feature parity and price, not control integrity. Security teams are told to meet deadlines instead of challenging system design. And compliance overrides capability as the default benchmark for “good enough.”

Compliance Is Treated as the Ceiling instead of the Floor

As many discussions at the recently concluded Identiverse conference made clear, compliance does result in security, but the kind that’s seemingly frozen in time: narrowly scoped, backward-looking, and audit-centric. Compliance-driven security doesn’t adapt as threats evolve. It doesn’t incentivize secure architectures. And it certainly doesn’t reward proactive, defense-in-depth investments like the ones being called for: session integrity, token binding, or real-time access evaluation.

This is what makes Patrick Opet’s open letter so relevant. Despite my reservations with where some of the blame was laid, what it clearly did was call out the need for all of us to stop settling for security theater, and to start building systems that are actually resilient to our ever-evolving threat landscape.

The hard truth is that we can’t expect (security) people to just do the right thing (cue the philosopher in my ear saying “duh!”). We need to create incentives for doing the right thing.

Secure-by-design isn’t rocket science, but it does require effort. It requires time, architectural rethink, cross-functional coordination, and long-term investment. Unfortunately in today’s landscape, it is hard to find places where that is rewarded (though I have seen some examples of teams really trying).

So if we want more secure-by-design adoption, we need to fix the incentive structures that govern behavior, both for vendors as well as buyers.

What A Good Incentive Structure Could Look Like

1. Shift Liability for Insecure Defaults: Right now, when SaaS vendors ship insecure implementations of OAuth or rely on fragile session management, it is the customer who typically pays the price in the event of a breach. Introducing clearer, shared liability standards – especially in cases of negligence or insecure-by-default configurations – would force vendors to take greater ownership of security posture, not just feature completeness. And I say this as someone who’s spent his life mostly on the vendor side of the equation.
2. Make Secure Architectures a Market Advantage: Security is often invisible in the buying process. That has to change. Procurement teams can start by asking tougher/deeper questions in RFPs. Go beyond “Do you support SSO?” and “Do you implement OAuth”, and start asking “How do you manage token lifecycle and session state?” and “are you enforcing DPoP or Mutual TLS?”. Independent benchmarking (think energy efficiency ratings or credit scores) could create a public, competitive metric for software security maturity. As a security industry, we need to make it much, much easier for buyers to do comparative evaluations.
3. Reward Security Investments with Lower Cyber Risk Premiums: Cyber insurance is a rapidly growing space. Providers are already building models to assess risk posture, and are in a perfect position to reward vendors and buyers who implement secure-by-design principles with lower premiums or higher coverage ceilings. This is already done in other domains (drivers that have done a defensive driving course are cheaper to insure). So why can’t we do the same for software with hardened session controls? Of course, the previous point about creating benchmarks and making comparisons easier become relevant here.
4. Measure the Right Things at the Board Level: How many posts have we seen about security and fraud reduction needing to become a board level priority. But it has to be done correctly. If the only metric security leaders are reporting to the board is “number of passed audits,” then secure-by-design will never get the visibility or funding it needs. We need to elevate identity posture, architectural maturity, and integration integrity to the same level as SLAs and NPS. Security isn’t just a function of the CISO. It’s a strategic business risk. And boards should treat it accordingly, giving CISOs the support they need.
5. Embed Security Into Corporate Culture: This one’s less about structure and more about mindset. Just as accessibility and sustainability are becoming table stakes in modern product development (sometimes through regulation), secure-by-design needs the same kind of internal advocacy. That means giving product managers and engineers the time, training, and tooling to make security a design decision, and not something relegated to a post-launch cleanup effort. It means moving security left and up the value chain.

This Isn’t About Blame. It’s About Incentive Design.

The clear need of the hour is to realign the system so that secure-by-design becomes the default outcome of doing good business. That means rethinking procurement, regulation, insurance, and organizational measurement. This is asking more of both enterprise buyers and vendors, but also giving them a reason to invest.

The technical playbook already exists. The missing ingredient is the will to change incentives. Until we fix that, we’ll keep pretending that compliance is enough, even as the cracks widen. We must stop rewarding checkbox security. Let’s start building systems that are actually built to withstand the world we live in.

Here’s an uncomfortable truth. Most of the risks being called out already have solutions – at least technically. The standards, protocols, and architectural patterns required to address them already exist. What’s lacking is the organizational will to implement them, the investment required to modernize infrastructure for security, and the discipline to prioritize long-term resilience over short-term delivery.

And this isn’t just a failure of vendors. It’s also a consequence of enterprise buyers rewarding compliance over capability, and executives framing security as a function of audit readiness rather than operational integrity.

Standards ≠ Security

Any conversation about this situation must necessarily discuss this fundamental disconnect. More than once, I’ve heard a senior IT leader assure me their APIs are “secure” because they’ve implemented OAuth. However, while standards do provide a foundation for security, they are not guarantees for security in of themselves. Implementation matters. Configuration matters. Layering matters. After all, deploying OpenID Connect for authentication means little if the authentication method is still password-based and single-factor.

Let’s look at Opet’s concern about session token theft, an increasingly common attack vector. This risk wasn’t unforeseen by those working on modern identity standards. It is among the many reasons why the Financial-grade API (FAPI) security profile was created by the OpenID Foundation. Originally designed for the financial sector, FAPI improves security for the OAuth and OpenID Connect standards by explicitly defining a security profile designed to ensure consistent and robust security measures across implementations of the standards with no room for misinterpretation. FAPI adds stricter constraints and requirements, like mandatory Strong Customer Authentication (SCA) and Mutual TLS, while also specifying additional controls like Demonstration of Proof-of-Possession (DPoP) and Proof Key for Code Exchange (PKCE). These aren’t experimental ideas. They’re proven, deployable measures that can be adopted by any organization (not just FIs), designed to eliminate many common attack vectors, including the ones highlighted in Opet’s letter.

Complementing this, the Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP) provide a mechanism to continuously align session state with real-time risk posture. CAEP enables cloud providers and enterprises to stay ahead of evolving threats by providing an event-based mechanism to add much needed context into the continuous adaptation and enforcement of access policies beyond the initial session established.

But here’s the problem: few organizations implement these controls at scale (unless forced by regulations like Open Banking). Why? Because they require real effort: redesigning app architectures, updating legacy integrations, and investing in a deeper understanding of token and access lifecycle management. And don’t get me started on SaaS providers that charge extra for foundational security capabilities (a practice we lovingly refer to as the “SSO Tax”), essentially compounding the problem since cybersecurity is already viewed as a cost-center.

The technology is here. The risk is clear. The inertia is organizational.

Compliance ≠ Security

It’s become cliche, but the fact remains that too many organizations still optimize for compliance, not security. Security leaders are pushed to check boxes and meet deadlines, not to redesign systems around identity assurance. Dev teams are incentivized to ship features fast, not to integrate securely. Auditors audit for usage of standards and control frameworks, not for the strength and resilience of those controls. Executive teams often lack visibility into how quickly small risks compound into systemic exposures. All while CISOs lack budget to implement the programs that could help mitigate the unfolding nightmare.

Don’t get me wrong. Compliance provides a crucial baseline of security controls that can be assessed and measured for existence. However, it doesn’t define how contextually strong or sufficient they are to meet an organizations security needs (if the organization can even define that). Put differently: compliance is a critical driver for putting better security in place, but it should be understood to be the starting point, not the end state.

Vulnerabilities like session hijacking and over-scoped permissions are therefore the entirely predictable outcomes of the fragile and hard-to-monitor architectures of systems that have been designed around minimum viable control.

We Don’t Need New Innovation. We Need New Priorities.

Cybersecurity threats are evolving at a rapid pace, and emerging technologies like AI are adding fuel to the fire. Compliance mandates will not be able to keep up (if they ever were), leaving organizations open to emerging threats unless they are proactive and innovative. To that end, many of the the tools are already there. Deterministic controls like phishing-resistant authentication, verifiable credentials, and more can help organizations dramatically reduce their attack surface. Comprehensive identity security posture management can help organizations gain visibility and remediate weaknesses in their identity infrastructure, automate controls, and proactively reduce potential risks to their digital ecosystem. FAPI, SSF, and CAEP are amongst a set of standards-based, security-focused architectural patterns that can be implemented today. And as overused as the term may be, the principles of Zero Trust are key: trust no session, verify continuously, and assume compromise as a starting condition.

The response to Patrick Opet’s letter shouldn’t be a scramble to invent something new. It should be a serious look at why we aren’t doing what we already know works. It’s time we recognize that the gap isn’t technical; it’s cultural and strategic. The change we need is a function of priorities incentives. As long as security is viewed as a cost center, where the cost of not being secure-by-design can be passed onto individuals and society, the fundamental calculus and therefore the current state of affairs won’t change. But that’s a discussion for a follow-up post.

The conference opened with a shot fired across the bow of the security and identity industry. Patrick Opet, CISO of JPMorganChase, published an open letter challenging the lack of secure-by-design thinking in modern integration patterns within the SaaS world, which is breaking down essential security guardrails. He specifically called out how the success of modern identity protocols (like OAuth) in enabling these integrations is actually leading to complacency in the pursuit of speed and convenience, and that improper setup of permission scopes and controls is creating vulnerabilities across a far broader and distributed attack surface.

In a way, his call-to-action both complements and contradicts what I saw at RSAC 2025. AI is speeding its way into the IT and SOC infrastructure for every organization – not as a theoretical capability, but as a triage partner, copilot, and even autonomous investigator (with decision maker just around the corner). When it comes to the SOC, however, it’s becoming clear that flashy dashboards aren’t enough any more. CISOs and practitioners are looking for proof that these tools drive outcomes at scale and don’t just shift complexity elsewhere. You can’t just sprinkle some AI on your existing offerings and call it innovation.

Beyond tooling, a deeper theme emerged: AI is the new operational surface and the new attack surface. From agent memory manipulation to prompt injection, organizations are discovering vulnerabilities that didn’t exist a year ago. And with AI wrappers, SaaS sprawl, and loosely governed agent identities, enterprise risk is evolving faster than our control models.

Here’s what stuck with me most:

• Identity is fragmenting fast: Humans, bots, APIs, and AI agents now live in parallel – each with its own lifecycle, permissions, and risks. Traditional IAM isn’t cutting it. Identity Security was one of the main themes, but few people outside of the identity bubble can properly define it. NHIs are taking over the world (hopefully not in the literal sense). Folks by and large understand that identity is key, and are paying increased attention, especially to delegated authorization, agent-specific policy enforcement, and fine-grained data access controls.
• We’re not there yet on passkeys: While the news on passkey adoption and rollout continues to be encouraging, discussions at the conference show that it isn’t quite breaking through yet. Usability is still a major concern, manageability is viewed as a challenge, and people not immersed in identity still have fundamental questions. World Passwordkey Day happened to fall during the conference, but it is clear that there is still a lot of (hard) work to do to overcome the hesitation many stakeholders still have.
• Memory is now a risk vector: Persistent agents that “learn” from interactions can also be misled by them. Attackers will go after context the way they once went after credentials. We need to secure not just the data agents access, but the logic and memory they build from it.
• Identity and security must enable, not obstruct: Too many orgs still see security as something to bolt on – or worse, slow things down. But the smart ones are building it into the architecture from day one, recognizing that sacrificing a little bit of speed for control and resilience is more efficient in the long run. Identity Security has a critical role to play in this area, in making security and enablement scale together.
• The cost curve needs a reality check: Using LLMs and AI isn’t cheap. A thousand alerts a day could cost millions in processing alone. AI-powered doesn’t always mean ROI-powered, and I was surprised that few of the customers (prospective or existing) of security tools were asking how their costs or subscription would increase due to the addition of AI powered features. We need to get sharper about value, not just capability.
• CISOs are tired. And worried: Patrick Opet isn’t alone. Everyone’s chasing context and control. While many tools are claiming to combat alert fatigue, that is viewed largely as a temporary fix. Beyond visibility, they want clarity, resilience, and the ability to scale good decisions fast. Their overarching need is to shift the focus from detect-and-respond to prevent-and-prove.

RSAC confirmed what many of us already felt: despite how we may feel about its current state, we have to accept that AI is becoming a business mandate. But without smart controls, agent-level governance, and identity models that match this new reality, we’re flying blind. We’re not just securing users anymore – we’re securing decision-making. It’s time to stop asking whether AI can do it, and start asking whether we’re building the trust infrastructure to let it.

I am incredibly proud of the team, and the platform we built – one that empowers businesses to engage securely and seamlessly with their customers, and creates lasting value for our customers and partners.  I want to express my deepest gratitude to my colleagues and partners at Uniken. Our collaborative efforts transformed the company and positioned it for long-term success, and I look forward to seeing you scale new heights.

As for what’s next – that’s TBD. Digital identity has never been more critical, yet the challenges facing the industry have never been more complex. Let’s see what the next chapter brings.

In the wake of OpenAI releasing Operator, a Computer-Using Agent (CUA), in research preview, I’ve read many breathless posts about the future of Web-based Agentic AI (as opposed to API-based Agentic AI), and how it makes every website “programmable”, even without APIs. If you have worked in software development, you can visualize the mechanics easily – it’s like giving a QA Automation tool like Selenium WebDriver a brain, so that instead of just automating web applications for rinse-and-repeat testing, it can actually read the data, make decisions, adjust course, and take action. That framing should also make it easy to immediately grok how this will break the identity and security infrastructure we currently have, or are putting in place. I mean, we have been dealing with these in our QA Automation projects forever. I thought I’d share the thoughts that immediately jumped to my mind, mostly because I need to not be the only one worrying about these (#MiseryLovesCompany).

1) Bypassing/Breaking/Compromising Authentication Mechanisms

Since CUAs rely on web-based browsing, they necessarily run into some of the same break points that QA automation runs into – like multi factor authentication, bot verification techniques, and more. Any CUA would currently have to give the user back control of the browser to take these actions before proceeding. This high friction point is going to run head first into consumer dissatisfaction and business mandates to “just make it work”, and all of us in identity can guess exactly what will follow:

• Users will hand over passwords to their Agent service so it can log in as them, or grant them access to their password managers (probably as a feature getting built into first the browser password manager and then the generic password managers).
• Users will turn off MFA to allow their agents to work.
• Any guesses on what will happen to passkeys? If syncing of the private key was the worst that you thought could happen….
• There will people looking at how authorized session hijacking can become a feature to leverage, much like how Selenium allows direct manipulation of cookies and local storage, enabling agents to hoover up valid session tokens and bypass login screens. Case in point: Build MCP servers for any website with automatic browser auth syncing
• Just like Selenium can sometimes bypass automation (bot) detection protections using headless browsing and user-agent spoofing, expect Agentic AI tools to develop capabilities to do the same.

2) Violating Authorization Boundaries (When They Exist)

QA Automation scripts often execute actions as a high-privilege test user (e.g., an admin account) to avoid breaking tests that are verifying functionality but not data or access restrictions. The rush to deploy Web-based Agentic AI tools will mean that like other tools of the past, it won’t be built with proper scope controls, thereby driving implementors to grant it excessive privileges. You can guess the rest.

As for consumer applications, those rarely have differentiated access control models built in for their users. That means a customer that wants to use a CUA, but limit what it can and cannot do will be out of luck. We saw this play out in the days of screenscraping-based personal finance applications, and how long it took for us to move everyone over to OAuth2 and FAPI as the better and more secure approach.

3) Weakening Security Controls

(aka “Is that a DDoS attack, or an army of Agents here to take advantage of the limited time deal we announced?”)

It won’t just be Authentication controls that are impacted. There are many security protections that will likely be obstacles in the path of Web-based Agentic AI. Would any of us be surprised to find out that IT teams were told to weaken or disable security mechanisms (e.g., Content Security Policy, SameSite cookies, Bot and DDoS detection) to facilitate automated agents, inadvertently creating vulnerabilities?

And these are just what immediately jumped to mind. I am sure there are many more that I’m not even thinking of.

Identity vendors and practitioners everywhere really need to shift into high gear to help organizations properly prepare for what’s headed their way. The demand to support Web-based Agentic AI will put a great deal of pressure on them to enable safe acceptance, and being the “Agent of No” (see what I did there) is not likely to go well. As for what can be done – more on that later.