Identity Security: How to Protect Digital Identities in Your Organisation

Identity security is the discipline of protecting digital identities, human accounts, service accounts, API keys, from compromise and misuse across every system they can access. It’s become the new perimeter because cloud adoption and remote work dissolved the old network boundary that traditional defenses were built to protect.

Firewalls and endpoint tools still matter, but an attacker holding valid, stolen credentials looks identical to a legitimate user from the network’s perspective. Digital identity protection now has to account for this reality directly: the access pathway itself, not just the network route to it, is what needs defending. This shift is why identity security has grown from an IAM feature into its own dedicated discipline with its own tools and specialists.

Is identity still the leading attack vector? The current numbers, reconciled honestly

Yes and no, depending on exactly what’s being measured. Verizon’s 2026 DBIR found vulnerability exploitation has overtaken credential abuse as the leading initial access vector, at 31% of breaches, while stolen or compromised credentials dropped to 13%, down from 22% the previous cycle.

Measurement	Finding	Source
Initial access vector (specific entry method)	Vulnerability exploitation leads at 31%; credentials at 13%	Verizon DBIR 2026
Overall identity involvement (full attack lifecycle)	Compromised credentials involved in 80%+ of breaches	Industry aggregate data
SOC-observed threat volume	Identity-based attacks made up 68.6% of threat volume in 2025	Expel Annual Threat Report

These numbers aren’t contradictory, they measure different things. DBIR’s 13% figure specifically tracks how attackers first got in, and vulnerability exploitation has genuinely become more common as that specific entry method. But identity remains deeply involved across the rest of the attack lifecycle, once inside, attackers still rely heavily on stolen or abused credentials to move laterally, escalate privileges, and reach sensitive data, which is what the broader 80%+ involvement figures and Expel’s SOC-observed 68.6% threat volume actually capture. The honest takeaway: don’t treat “credentials at 13%” as evidence identity risk is shrinking. It means the front door has shifted while identity remains central to nearly everything that happens after any door opens.

Why IAM alone can’t stop what it can’t see: the IAM-ITDR gap

An attacker using stolen but valid credentials passes every IAM policy check by definition, since IAM verifies identity and enforces permissions, it doesn’t ask whether the behavior after login actually matches that account’s normal pattern. This is the IAM-ITDR gap, and it’s where most real identity breaches happen.

IAM vs ITDR comes down to timing and purpose. IAM operates at the point of access, deciding whether to grant entry based on credentials and policy. ITDR, Identity Threat Detection and Response, operates continuously after that decision, watching for behavioral signals that something is wrong even though the login itself looked legitimate. An account logging in from an unusual location at an unusual time, suddenly accessing systems it’s never touched before, is invisible to IAM, which already approved the login, but it’s exactly the kind of anomaly ITDR is built to catch. Businesses running mature IAM without any ITDR layer have strong front-door verification and effectively no visibility into what happens once someone, legitimate or not, is already inside.

Detection isn’t containment: the gap current research just confirmed

Detecting an identity attack and stopping it are two different capabilities, and current research shows a real, measurable gap between them. The 2026 SANS State of Identity Threats & Defenses Survey found 68% of organizations detect identity attacks within 24 hours, but only 55% contain them in that same window, what SANS calls the deployment vs resilience gap.

This finding matters because it directly challenges a decade of industry assumption that better detection tooling alone would solve identity risk. Organizations have genuinely invested in the sensors, SSO, MFA, monitoring, needed to hear the alarm, but SANS’s data shows many haven’t built the operational capability to actually put out the fire once it’s ringing. A 13-point gap between detection and containment translates to real dwell time: attacks that get noticed within a day but aren’t actually shut down for longer, giving attackers extra time to move laterally, exfiltrate data, or establish persistence before response catches up. If your organization measures success purely by “time to detect,” this research is the direct evidence that metric alone doesn’t tell you whether you’re actually safe. Time to contain deserves equal, if not greater, weight in how identity security programmes get evaluated.

ISPM vs ITDR: prevention and detection, working together

ISPM, Identity Security Posture Management, continuously discovers and fixes identity weaknesses, misconfigurations, dormant accounts, excessive permissions, before an attacker exploits them. ITDR detects and responds to active attacks already underway. They answer genuinely different questions and work best deployed together, not as substitutes for each other.

	ISPM	ITDR
Timing	Before an attack (preventive)	During an attack (detective/responsive)
Core question	Does current access create exposure?	Is this behavior an active attack?
Scope	Human and non-human identity posture	Real-time behavioral anomalies

ISPM closes the gap left by periodic access reviews, which typically run quarterly and miss entitlement drift, dormant accounts, and machine identity sprawl accumulating between cycles. ITDR closes a different gap entirely, the window between a valid login and the moment behavior reveals something is wrong. Running ISPM without ITDR means your identity posture might look clean on paper while an active attack goes undetected. Running ITDR without ISPM means you might detect an attack quickly while the underlying misconfiguration that enabled it, an over-privileged service account, a dormant admin credential, remains unfixed and ready to be exploited again. Mature identity security programmes deploy both, treating ISPM as the proactive layer and ITDR as the reactive one.

The growing risk of non-human identity: APIs, automation, and AI agents

Non-human identities, service accounts, API keys, OAuth tokens, and increasingly AI agents, now outnumber human identities by a wide margin, with estimates ranging from roughly 45 to 1 up to more than 80 to 1 depending on the environment measured. These identities often carry elevated privileges with far less oversight than human accounts receive.

This gap exists because non-human identities were historically treated as infrastructure, set up once and forgotten, rather than as identities requiring the same lifecycle discipline as an employee account. A well-known, named example of this risk in practice is Kerberoasting, an attack technique targeting Active Directory service accounts specifically: an attacker requests a service ticket through the Kerberos authentication protocol, then attempts to crack the ticket’s encryption offline to recover the service account’s password, all without triggering a failed login alert, since the initial request looks like normal, legitimate protocol activity. Service accounts frequently use old, weak, or never-rotated passwords precisely because nobody logs into them directly to notice, making them an efficient, quiet target. As businesses adopt AI agents for operational tasks, the same risk pattern applies at a larger scale, an agent with broad, standing API access represents the same exposure as an over-privileged service account, just with less human attention paid to reviewing it regularly.

Real incidents that prove the case: Snowflake and beyond

Two real, well-documented incidents show identity-based compromise defeating traditional defenses entirely. The 2024 Snowflake breach affected roughly 165 customer organizations, including AT&T and Ticketmaster, through credential stuffing using previously stolen, never-rotated passwords against accounts lacking MFA. Separately, the Russian state-linked group Midnight Blizzard compromised Microsoft’s own corporate email by password-spraying a legacy test account that also lacked MFA.

The Snowflake case is instructive precisely because no central platform breach occurred, attackers used valid credentials, harvested by infostealer malware and sold on dark web markets, some of which had gone years without rotation. From the platform’s perspective, every login looked legitimate, since the attackers held genuinely valid keys. The Midnight Blizzard case against Microsoft followed a similar identity-first pattern but added a second layer: after gaining initial access through a password-spray attack against an unmonitored legacy account, the group abused OAuth application permissions to gain persistent access to executive email accounts, a technique conventional endpoint detection tools aren’t built to catch, since it exploits legitimate application authorization rather than malware. Both incidents share the same root lesson: identity-based attacks succeed specifically because they look like normal, authorized activity to the systems meant to stop them.

How does this connect to your existing IAM platform?

Your existing top IAM solutions, whatever platform handles authentication and authorization today, remain necessary but insufficient on their own, since IAM verifies identity at the point of login and doesn’t monitor ongoing behavior afterward. Adding ITDR and ISPM layers on top of existing IAM investment closes exactly the gap the Snowflake and Midnight Blizzard incidents exposed.

What is access control in security, fundamentally, is deciding who gets to do what, the core function IAM performs well. Identity security extends that foundation by adding continuous verification after the access decision, watching for behavior that contradicts what a legitimate, authorized identity would normally do. Most IAM platforms today offer some native ITDR-adjacent features, anomaly detection, risk-based authentication, but a dedicated ITDR or ISPM layer typically provides deeper, cross-platform visibility than a single IAM vendor’s built-in monitoring alone. Before assuming your IAM platform already covers this gap, ask directly what percentage of post-login behavioral anomalies it actually flags, versus what it simply authenticates and forgets.

A realistic starting point if a dedicated ITDR platform isn’t in reach yet

Start by inventorying your non-human identities, service accounts, API keys, and integrations, since this single exercise typically surfaces more unmanaged exposure than any other first step, and doesn’t require purchasing a dedicated platform to begin.

Most businesses have never fully catalogued their service accounts and API keys, which means the very first ISPM-style action, simply knowing what identities exist and what they can access, delivers real risk reduction before any tooling purchase. Pair that inventory with enforcing MFA specifically on any account currently missing it, prioritizing service and admin accounts first, since these are consistently the accounts attackers target precisely because nobody expects them to need protecting. Cyber Security Solutions Ltd helps clients run exactly this inventory-first exercise before recommending any dedicated ITDR or ISPM platform purchase, since the businesses that start here consistently find their highest-risk gaps sitting in accounts nobody was actively monitoring, not in the tools they’d already invested in.

Conclusion

Identity security now determines whether the rest of your defenses matter, since an attacker holding valid credentials walks past network and endpoint controls entirely. Start with a non-human identity inventory and MFA enforcement on every account that’s missing it, then build toward ISPM and ITDR coverage as budget allows. If you want help auditing your current identity exposure, Cyber Security Solutions Ltd can walk through it with you at cybersecuritysolutionsltd.com.