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
Thanks again to all of our speakers, partners and everyone who came along and got involved.
Now for the useful stuff, here were some of the major takeaways from the event:
One of the strongest points from Edna Randiki at Auto & General was that a lot of our existing Identity controls are simply too slow for AI Agents. A quarterly access review might work for a person, but it does not work as well when an agent can take thousands of actions before the next review happens.
Her framework was built around five things: Identity, Context, Time, Authority and Purpose, with all five needing to be checked as the agent acts rather than assumed from the start.
She also introduced the idea of "least agency", which is basically least privilege for AI Agents. Give the agent one job and only the access and freedom it needs to do that job.
One stat that stood out from our Deloitte and Auth0 session was that applications, service accounts and agents can now outnumber humans by around 50:1 in a typical enterprise.
The problem is that the majority of the room said their current NHI governance still comes down to basic service account controls with a lot of the enforcement done manually.
So before companies get too complicated with AI Agent governance, the first job is pretty simple: know what identities exist, what they have access to and who owns them.
That does not necessarily mean forcing everything into one system. In most large companies that probably is not realistic anymore, but there still needs to be one place where teams can see the identities, relationships and access sitting across all of those different systems.
We asked the room what their PAM currently covers and 56% said human users only, not machines or AI Agents.
That is a pretty big gap when privileged access now sits across service accounts, API keys, cloud workloads and AI Agents as well as traditional admins.
One point from the panel was that agents should have their own dedicated Identity rather than sharing or inheriting somebody else's. If five agents are all using the same system account, it becomes very difficult to work out which one actually did something when there is a problem.
The end goal discussed was just-in-time access with as little standing privilege as possible, whether the Identity belongs to a person, machine or agent.
One of the best examples from our Digital Identity sessions came from AusPaymentPlus, where around 500,000 people have used their ConnectID service to verify their identity with Telstra in recent months.
The same model could also be used for age verification. Instead of giving a social media company your passport, driver's licence or date of birth, your bank could simply confirm "over 16: yes".
The platform gets the answer it needs without getting a load of extra personal information.
That was probably the main takeaway for me. Digital Identity should be less about proving exactly who you are every time and more about proving the specific thing that is actually needed.
You can view the full list of session slides here: [VIEW SLIDES]
Join over 100 identity leaders from across the world on our Identity Leaders Network WhatsApp Group.
We have spent a lot of the last few issues looking at how attackers get around stronger authentication, and the same thing keeps coming up.
They do not necessarily need to beat MFA if they can get the token or session that comes after it.
NIST and CISA have now published new guidance specifically on protecting Identity and access tokens from theft, forgery and misuse, covering things like token verification, lifecycle controls and monitoring.
Probably the best example this fortnight was EvilTokens, a phishing service Microsoft says helped compromise more than 12,000 inboxes across 10,000 organisations.
EvilTokens abused Microsoft's legitimate device code flow. The attacker starts a login and sends the victim a code, the victim enters it into the real Microsoft login page and completes their normal authentication, but what they have actually done is approve the attacker's session.
The attacker therefore does not need to steal the password or beat MFA themselves. Microsoft gives them a valid token after the victim completes the authentication.
Microsoft is now recommending that companies block device code authentication unless they actually need it.
Varonis also published its TrustSink research this month, where a highly privileged attacker could register a rogue external MFA provider inside Entra and put a fake password prompt into an otherwise legitimate Microsoft login.
This one is a bit different because the attacker already needs significant access, but again the weakness is not really the MFA itself. It is everything sitting around it.
This also follows JSCeal from our last issue, where malware could steal a Google session cookie from a compromised device and potentially reuse it without authenticating again.
So I think the bigger point for Identity teams is that protecting the login is only part of the job now.
You also need to think about what happens to the token after the login succeeds, how long it lasts, where it can be used and how quickly you can kill it if something goes wrong.
OpenID Connect Key Binding has just reached its first Implementer's Draft, NIST is pushing stronger token lifecycle controls and Microsoft is recommending device code is turned off where it is not needed.
Make tokens short-lived, bind them where possible, limit where they can be used and make sure you can kill them quickly.
SPIFFE/SPIRE comes up a lot when people talk about doing machine identity properly. Rather than workloads sitting on long-lived passwords or API keys, SPIFFE gives them short-lived cryptographic identities.
Unit 42 has now published research looking at what happens when an attacker is already inside that environment.
Their researchers found that an attacker with root access to a compromised Kubernetes node could manipulate the information SPIRE uses to work out which workload it is talking to, potentially allowing them to impersonate another workload on the same node.
It is important to put that in context. The attacker already needs root access, Unit 42 had not seen the technique used in the wild, and this does not mean SPIFFE itself is broken.
The interesting part is what it says about machine Identity more broadly. You can have the right Identity standard in place, but that Identity still has to trust something underneath it.
This comes as the IETF's work around workload Identity keeps moving, including its new AI Identity Management System (AIMS) working-group draft which treats AI Agents as workloads.
So if you deployed SPIRE because it was the safer answer for workload Identity, that probably has not changed.
The next question is what happens to your Identity controls after somebody owns the workload underneath them?
A lot of the Agent Identity standards work so far has focused on who the Agent is and what it is allowed to do.
The next problem is what happens after that. New drafts are now looking at how you record exactly what an Agent did, and how you revoke its authority if it has already handed part of the job to another Agent.
Payments are moving into the same area too, with EMVCo publishing a draft framework for proving that a consumer actually authorised an Agent to make a payment on their behalf.
Oktane is on this week and Cross App Access is one of the more interesting things to watch. It lets companies control which applications an AI Agent can access on behalf of a user, with those connections managed through Okta rather than relying on the user to approve them each time.
We have covered Okta's Agent discovery work, MCP capabilities and Permiso acquisition across the last few issues. The common theme is pretty simple: AI Agents are starting to be treated like another Identity that needs to be discovered, registered and controlled.
The UK Government is rolling passkeys out across GOV.UK One Login to more than 23 million users, after an initial trial with over 300,000 people.
Singapore is heading the same way, expanding passkeys across Singpass and more devices.
We have spent a lot of time covering the attacks and implementation problems around passkeys, but adoption is still moving quickly. They are now starting to become part of national Identity infrastructure, not just something used inside enterprises.
The OpenID Foundation published a piece this fortnight looking at Australia's age assurance rules and the different ways somebody could prove they are old enough to access a service.
The part that stood out was the same minimum disclosure point that came up at our Melbourne Summit. A platform might need to know that somebody is over 16, but that does not mean it needs their full name, date of birth, licence number and address.
That is where Digital Identity becomes useful: prove the thing that matters without handing over everything else.
Identity at the Center released #449 – Decoded: Transaction Tokens with George Fletcher, which fits pretty closely with our token story above. It looks at short-lived transaction tokens, how they carry context through different services and where the same model could apply to AI Agents.
They also released #447 with Andi Hindle, previewing Authenticate 2026 and covering passkeys, Digital Identity wallets, non-human authentication and where Agent authorisation is heading.
Authenticate U.S. 2026 takes place from 19–21 October in Carlsbad, California, with this year's program covering passkeys, Digital Identity and Agent authentication.
SailPoint Navigate is in Austin from 5–8 October, followed by London from 2–4 November.
The Gartner Identity & Access Management Summit takes place from 7–9 December in Las Vegas.
And our Identity World 2027 series is now live, with five IAM events across Sydney, Melbourne, New York, London and San Francisco: Sydney – 18 February, Melbourne – 17 March, New York – 6 May, London – 16 June and San Francisco – 3 November.
Last issue I asked how companies that already have Windows Hello for Business rolled out are handling Microsoft's move to make passkeys the default authentication method.
I haven't had enough replies yet to pull together anything useful, but a related question has come up:
Are users ending up with passkey as their primary authentication method when you didn't intend them to, and if so, how are you controlling it?
If you are dealing with this 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 →