The fortnightly read for identity practitioners.
Clear breakdowns of the standards, tools and threats shaping the industry.
Views and interviews from identity practitioners doing the work.
What vendors are launching, what is changing and what is actually worth paying attention to.
THIS NEWSLETTER IS POWERED BY CLUTCH
Louis and his team tested passkey implementations across 103 websites to see whether they actually worked the way WebAuthn says they should. The results were pretty surprising, with 18 critical vulnerabilities, 53 high-severity vulnerabilities and not one of the 103 websites passing every test.
Louis was clear that failing a test did not automatically mean somebody could take over the account, but some of the problems were still pretty basic. A few websites were not properly checking the cryptographic signature behind the passkey, while others had issues around how passkeys were registered, deleted or linked back to accounts.
In some cases the researchers were able to overwrite another user's passkey or register their own passkey against somebody else's account.
Probably the most surprising finding was that bigger websites actually performed worse. Louis couldn't say exactly why, but one theory was that larger companies are more likely to build parts of the authentication process themselves rather than rely on established libraries, which obviously gives you more places to get something wrong.
This follows pretty closely from what we have covered in the last few issues. We have looked at passkey enrolment attacks, compromised endpoints, password resets and account recovery, and now poor implementation.
Again, the actual passkey seems to be holding up pretty well. It is everything around it that keeps causing the problems.
The team's testing tools are open source as well, so companies can use them against their own implementations.
Also worth noting that two things we have been following went live on 1 September. Microsoft has started making passkeys the default authentication method in Entra and OpenAI's Trusted Access for Cyber program now requires hardware-backed passkeys.
So adoption is moving quickly. The implementations around them probably need to keep up.
Join the Melbourne Identity, Authentication and Access Management Summit held at Collins Square Centre.
Free to Attend with speakers coming from brands such as Telstra, Ramsay Healthcare, Auto & General, NAB and JB Hi-Fi.
We have spent a lot of time recently talking about how companies should govern their own AI Agents, but this fortnight had a good reminder that attackers are figuring out agents as well.
Google Threat Intelligence Group published research into how threat actors are moving from using AI for individual tasks towards using it to run larger parts of attacks.
One example involved a financially motivated attacker who had already compromised a cloud environment. They used an AI coding chatbot and agent instructions to help scan the environment and harvest credentials, with thousands of credentials collected in less than six hours.
Unit 42 also published an investigation where AI was used during a real enterprise intrusion to help investigate systems, find credentials and work out where to move next.
What stood out to me across both stories was really just the speed. A lot of Security and Identity processes still work on the assumption that somebody has a bit of time to see an alert, investigate it and then decide what to do.
That starts looking pretty slow if an attacker can scan hundreds of systems and test thousands of credentials while that is happening.
It does not mean these attacks are suddenly completely autonomous. Humans are still directing a lot of this, but one person can now do much more in a much shorter period of time.
For Identity teams, that probably puts much more pressure on response times. If a credential suddenly looks suspicious, how quickly can it actually be disabled? If an attacker is trying hundreds of credentials at once, are you still relying on somebody seeing an alert and responding manually?
The interesting part is that a lot of companies are still working out how to inventory, authenticate and govern their own AI Agents, while attackers are already working out how to use agents against them.
Phil Windley published a piece this week called Authentication Is Largely Solved. Authorization Isn't.
I don't think I would go quite that far, especially after what we have covered in the last three issues, but I do think the basic point is right.
We are getting much better at proving who somebody is. The harder problem is increasingly what they should actually be allowed to do once they are in, and AI Agents make that much more obvious.
Knowing which agent is acting is useful, but you still need to know what that agent can actually do. Can it read Salesforce, update it, export thousands of customer records or hand part of the task to another agent?
A few other things published this fortnight are basically making the same point.
IDPro published a piece on how messy the terminology around authorisation has become, while the Decentralized Identity Foundation published one arguing that simply blocking delegation between agents is not necessarily the answer either.
If an agent is allowed to perform a task and needs to hand part of that task somewhere else, the better model may be to let it delegate a smaller amount of authority rather than blocking delegation completely.
There have also been several new Internet-Drafts looking at agent delegation. The basic problem they are trying to solve is pretty simple: if I give Agent A permission to do something and Agent A gives part of that job to Agent B, can I still prove what Agent B was allowed to do and where that authority originally came from?
This actually came up at our New York Identity Summit as chain of custody. If an agent takes an action, companies need to be able to trace where the authority came from and who or what was responsible for giving it that authority.
The vendors are moving pretty quickly here too, with Okta launching more agent discovery and MCP capabilities and CrowdStrike launching an Agentic Identity Provider.
It feels like the conversation is moving pretty quickly from:
How do we authenticate an AI Agent?
towards:
What is this agent actually allowed to do?
The second question is probably the harder one.
Amazon says more than 175 million customers now have passkeys enabled on their accounts.
We have covered attacks against enrolment, compromised endpoints, account recovery and bad implementations, but none of them have really changed where passkeys themselves are heading.
The problems we keep seeing are around everything sitting around the passkey rather than the passkey itself.
Researchers have disclosed a FreeIPA vulnerability chain which could allow an anonymous client to create a Kerberos identity and potentially end up with administrator privileges.
The attack combines a FreeIPA access-control issue with another vulnerability in 389 Directory Server. FreeIPA has fixed its side in version 4.13.4.
This comes straight after the Keycloak password reset flaw we covered last issue. Completely different vulnerability, but another Identity platform potentially going from unauthenticated access through to admin.
New research into JSCeal shows malware stealing Google session cookies from a compromised machine, which can then potentially be reused without the attacker needing to authenticate again.
So again, the attacker does not necessarily need to beat MFA if they can steal the session after the user has already authenticated.
Identity at the Center released episode #446 with Rick Scot, Global CIO and CISO at Elevate Textiles, looking at how Identity changes when AI Agents start acting inside the business.
The Identity Jedi Show also has a new episode with Amit Saha on runtime authorisation for AI Agents, including delegation chains, permissions and making access decisions while the agent is actually taking the action.
Our Melbourne Identity, Authentication and Access Management Summit is next week on 16 September at Collins Square, with speakers joining from Telstra, Ramsay Healthcare, Auto & General, NAB and JB Hi-Fi.
The event is run by the publisher of Identity Briefing and is free to attend for Identity practitioners.
FIDO's Authenticate U.S. 2026 is also coming up from 19–21 October in Carlsbad, California.
Oktane 2026 is also coming up on 22–24 September in Las Vegas.
SailPoint Navigate takes place in Austin from 5–8 October.
Microsoft has now started making passkeys the default authentication method in Entra.
One question I have seen come up is what happens when companies already have Windows Hello for Business rolled out.
If your users already have Windows Hello for Business, how are you approaching the passkey rollout on top of it, and what is causing problems?
If you are going through it now, I would be interested to hear what you are seeing.
Get in touch at danny@clutchgroup.co.
Identity Briefing is published fortnightly by Clutch Group, which runs the Identity Leaders Network, Identity Briefing and the Global Identity Summit series.
Know someone who should be reading it? Forward this on.
The Identity Leaders Network is a free, global and vendor-neutral identity community.
The group comes together for virtual roundtable discussions, peer-matching meetings, dinners and through the community WhatsApp channel.
The fortnightly read for identity practitioners.
Original data from identity leaders, one proper deep dive, and the fortnight's news that actually matters. Free, every two weeks.
You're subscribed. Read the latest issue →