We’ve all spent millions of pounds on tens of tools with a simple aim; to stop the bad guys breaching our multi-layered security perimeter but the bad guys are just logging in with legitimate credentials. How are they doing it, and what can we do to stop it?
As I’m sure those who have read my blogs know I was once in the ‘buy best-of-breed’ camp for many years – I was very much an advocate of buying a bigger wall, adding more moats and adopting the defence-in-depth approach. I wasn’t alone, and many businesses still take the same approach but bad actors are wise to it. If they aren’t using AI to chain vulnerabilities together to exploit your various lines of defence, then they’re buying stolen credentials, hijacking session cookies or tricking employees using social engineering.
Surely this isn’t common though right? Working at Palo Alto gives me a great insight of how plenty of customers operate and I can tell you many of them say the same things.
“Our identities can’t be stolen , we’ve got Microsoft EntraID implemented as part of our M365 subscription”
“All of our accounts have MFA”
“We have robust processes in place so we don’t fall foul of script kiddies trying to impersonate our users”
Let’s start by reframing what an identity used to be, and what it is now. In years gone by, an identity was simply a user account in an Active Directory domain. That user account may have been a member of one or more security groups and external apps would connect to Active Directory for authentication.
Then cloud ‘happened’ and third party identity providers came along, such as Okta, Ping, and EntraID – often synced those user accounts from AD but enabled SSO via SAML and gave organisations the ability to authenticate users in external web apps.
The key element here is that it was often a 1-2-1 mapping of employees to user accounts or identities with the exception of shared or admin accounts.
With the advent of modern apps, there has been an explosion of machine identities. In many organisations there are 45 machine identities for every human worker. These could be API tokens, SSH keys, service accounts and now autonomous AI agents.
The big problem is that we’ve focused so hard on securing humans – from hardware MFA tokens, to biometrics and onboarding and offboarding workflows we’ve neglected those machines identities that often have static API keys or certificates, hardcoded tokens or forgotten or unmonitored keys.
Let’s talk about a real-world example in 2026. Imagine we’ve got an hardcoded API key in a terraform script that is used to connect and commit code to a GitHub repository. That API key, because the dev is lazy has got full Administrator rights over the AWS account that the terraform connects to. The bad actor gains access using a session hijack or by having gained access to the developer workstation. It silently scans internal repos for keys, waits till 2am on a Sunday morning and begins exfiltrating data from the organisations S3 buckets or customer databases.
Traditional security tools saw nothing wrong.
EDR: No malware installed
NGFW: Legitimate traffic from dev workstation to AWS repos encrypted over HTTPS
IdP: No failed password attempts or suspicious logins because the attacker used an API key not a human identity
Cloud Native Security Tooling: a legit, active API key was used, so nothing to flag.
The other obvious scenario is admin accounts or accounts with long standing privilege, available 365 days a year whether they’re in use or not. Yes, Privileged Access Management (PAM) is around but it was built in the world of traditional humans. They focus on who is checking out a password to human admins not what those accounts are doing after they leave the vault.
In the world of cloud, once an admin checks out a credential or service account is granted an IAM role that identity has that high-level access 24 hours a day. For example, if a DBA needs admin rights to patch a system for 30 mins on a Tuesday night, they are often granted standing privileges that sit dormant, vulnerable, and fully exposed for the remaining 364 days of the year so on Sunday night at 2AM when everyone is asleep, that’s when the attacker hits, using that exact over-privileged identity.
The key takeaway is that bad actors don’t need complex exploits, they just wait for and harvest or buy these dormant keys. Once they have the keys, the real question becomes: what security model is actually protecting those identities?
- Legacy Security: “Is this credential valid?” (If yes, allow access)
- Modern Security: “Is this behaviour normal for this identity right now?”
If your answer is Legacy, then you need to look at your tooling and shift from perimeter defense to identity-centric threat detection. That seems like a lot of buzzwords Sam! What does this all mean? Hold my beer…
- Discover & Govern Non-Human Identities (NHIs): Inventory every API token, service account, and AI agent across your cloud estate with automated lifecycle tracking and rotation.
- Kill Standing Privileges with Ephemeral Access: Move to Just-In-Time (JIT) access models—credentials should auto-expire the minute a task finishes.
- Deploy Identity Threat Detection and Response (ITDR): Implement real-time behavioral monitoring that correlates identity telemetry across IdPs, cloud environments, and endpoints to catch anomalous behavior (e.g., unexpected 2 AM bulk data exports).
- Consolidate Telemetry Silos: Merge endpoint, network, and cloud identity contexts into a single unified platform rather than relying on fragmented “best-of-breed” tools.
If you take away just one thing from this post, let it be this: attackers don’t need to craft complex zero-day exploits when they can simply buy stolen session tokens for £10 or scavenge forgotten API keys from an unmonitored script.
Identity is the new perimeter—and non-human identities are your biggest unmanaged attack surface. It’s time we stop treating identity security as an HR onboarding task and start treating non-human identity detection as a core pillar of the modern SOC.
