Continuous identity security is now the breach detection problem

At a glance

What this is: The article argues that identity compromise now shows up as subtle behavioural drift, not obvious alarms, and that continuous identity security is necessary to catch it early.

Why it matters: It matters because IAM, PAM, and IGA teams need to detect abuse across human and machine identities before attackers establish persistence and operate below the radar.

By the numbers:

• More than 80% of breaches now involve some form of identity compromise.
• 69% of organisations now having more machine identities, ities than human ones, identity monitoring must extend well beyond user accounts.

👉 Read Hydden's analysis of early identity compromise signals and detection gaps

Context

Identity compromise now appears as behavioural drift, not a single loud alert. In practice, the problem is that legacy IAM, PAM, and IGA controls are often tuned to changes that happen at review cadence, while attackers move through accounts, sessions, and machine identities in near real time.

The article focuses on the gap between identity ownership on paper and identity usage in reality. That gap matters across human identity, NHI, and privileged access programmes because attackers exploit dormant accounts, out-of-band machine identities, and weak MFA paths that existing control points often miss.

Key questions

Q: How should security teams detect identity compromise before attackers establish persistence?

A: Focus on behavioural change, not just login success. Prioritise new account creation, role changes, dormant accounts becoming active, repeated MFA prompts, and unusual session timing. Then correlate those signals with ownership and privilege data so the team can separate legitimate administrative work from attacker persistence attempts.

Q: Why do machine identities increase the risk of hidden attacker activity?

A: Machine identities often lack clear ownership, consistent review, and human-visible usage patterns. That makes them ideal for attackers who want valid access without noisy compromise indicators. If the organisation cannot explain what a token, service account, or certificate is for, it is already operating with blind spots.

Q: What do security teams get wrong about MFA as a defence signal?

A: They treat MFA success as proof of safety, even when an attacker is repeatedly prompting, downgrading factors, or enrolling a new device. The real warning is control erosion. Once fallback paths become easier to use than the primary method, authentication no longer provides reliable assurance.

Q: Who is accountable when shadow accounts or orphan identities are used in an attack?

A: Accountability sits with the identity governance function that failed to assign ownership, monitor usage, and remove unnecessary access. If an account cannot be tied to a responsible business owner, a system owner, and a lifecycle process, the organisation has created an unmanaged trust path that attackers can exploit.

Technical breakdown

Why identity compromise often starts with persistence, not noise

Attackers rarely need to announce themselves once they have valid access. They create persistence by adding accounts, changing roles, or resurrecting dormant identities, then use those identities in ways that blend into normal administrative activity. The technical problem is that these actions can be legitimate on their face but suspicious in sequence, especially when they occur outside expected business patterns. Behavioural detection depends on joining identity events, session context, and ownership metadata, not just authentication logs.

Practical implication: correlate account lifecycle events with session timing and privilege changes so persistence attempts become visible before they spread.

Machine identity misuse is a visibility problem, not just a scale problem

Machine identities such as service accounts, tokens, and certificates are easy to miss because they do not follow human review rhythms. When they are over-privileged or unmanaged, attackers can use them to move laterally without triggering user-centric controls. The issue is not only that there are more of them, but that ownership, purpose, and expected behaviour are often undocumented. That leaves defenders with blind spots where misuse looks like routine workload activity until impact is already underway.

Practical implication: inventory machine identities with owner, purpose, and permitted scope, then monitor for use outside those boundaries.

Why MFA failures and fallback paths are high-value signals

Repeated MFA prompts, MFA bombing, weak fallback methods, and changes to less secure factors can indicate credential theft or social engineering in progress. The technical signal is not just failed authentication, but the pattern of escalation from one verification method to another. Attackers often probe these paths because the identity has already been accepted once, which means they are now testing the resilience of step-up controls. If MFA policy is inconsistent across systems, the attacker only needs one weak path.

Practical implication: standardise MFA enforcement and alert on factor downgrades, repeated prompts, and new device enrolment for privileged identities.

Threat narrative

Attacker objective: The attacker’s objective is to turn a single identity foothold into durable, low-visibility control over privileged systems and data.

1. Entry begins with compromised credentials, a hijacked session, or exploitation of a vulnerable system that exposes identity material the attacker can reuse.
2. Escalation follows when the attacker creates accounts, modifies roles, registers new MFA devices, or abuses machine identities to establish durable access.
3. Impact occurs when the attacker operates below the radar through privileged access, unmonitored service accounts, or shadow identities to maintain persistence and reach sensitive systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Continuous identity security is now a control plane problem, not a point-in-time review problem. Quarterly access reviews and static discovery create a false sense of coverage because attackers do not operate on review cycles. The field needs to treat identity as a live signal set that includes account creation, role change, MFA drift, and machine identity use. Practitioner conclusion: if the control cannot observe behaviour continuously, it cannot credibly claim identity assurance.

Identity ownership is the named concept this article exposes. Ownership on paper is not the same as ownership in operation, and attackers exploit that gap by creating or reusing identities that are hard to trace back to a responsible party. When cloud admin accounts, API tokens, and local system identities sit outside clear accountability, the governance model has already failed. Practitioner conclusion: identity governance must track usage, responsibility, and administrative control together.

Machine identity sprawl is turning hidden access into the default breach condition. The article’s reference to 50 to 80 times more machine identities than human identities is a warning that human-centric monitoring assumptions are no longer sufficient. A machine identity can be valid, active, and highly privileged while remaining effectively invisible to traditional review patterns. Practitioner conclusion: NHI governance has to become operationally continuous, not periodically reconciled.

MFA is only a control if the fallback path is also controlled. Repeated prompts, downgrade to SMS or email, and new device enrolment are not noise. They are the point where authentication starts to bend under attack pressure. Practitioner conclusion: teams should treat fallback authentication as a privileged surface, not a convenience feature.

Behaviour-based identity monitoring is the practical bridge between IAM and vulnerability management. The article is right to connect CVE exploitation to identity compromise because attackers often move from system weakness to identity abuse in one chain. That means exposure management and identity telemetry can no longer live in separate programmes. Practitioner conclusion: a vulnerability without identity context is incomplete risk data.

From our research:

• 53% of organisations have experienced a security incident directly related to machine identity management failures, according to The Critical Gaps in Machine Identity Management report.
• Only 38% have automated certificate lifecycle management in place, which leaves expiry, renewal, and ownership gaps exposed to abuse.
• For a broader breach pattern view, the 52 NHI Breaches Analysis shows how credential exposure and unmanaged access turn into persistence.

What this signals

Identity monitoring is becoming a programme-level requirement, not a detection-team nice-to-have. If more than 80% of breaches now involve identity compromise, the programme implication is clear: IAM, PAM, and exposure management need shared telemetry and shared ownership for identity risk. Teams that still separate authentication, privilege, and workload identity will continue to miss the sequence attackers actually use.

Hidden access is the real operational hazard. The organisation that cannot explain its shadow accounts, orphan accounts, and unmanaged machine identities is already running a fragmented trust model. That is why controls like continuous discovery and owner validation matter more than another periodic recertification cycle.

Machine identity sprawl changes the baseline for every identity programme. With 69% of organisations now having more machine identities than human ones, the operating assumption that humans are the primary review population no longer holds. IAM roadmaps should reflect that shift now, not after the next incident.

For practitioners

• Implement continuous identity discovery Move beyond quarterly access reviews and point-in-time scans. Continuously identify human accounts, service accounts, tokens, certificates, and local identities, then compare activity against expected ownership and purpose.
• Correlate vulnerability and identity telemetry When a CVE affects a system that can issue or store credentials, join exploitability data with identity context so the security team can see whether the attacker could pivot into accounts, roles, or secrets.
• Alert on identity behaviour drift Flag dormant accounts that reappear after long inactivity, abnormal session duration, access at unusual hours, repeated MFA challenges, and machine identities that touch systems outside their normal role.
• Treat fallback MFA as a control surface Remove weak fallback methods where possible and generate alerts when identities are downgraded to SMS, email, or other less secure factors, especially for privileged users and admin accounts.
• Audit shadow and orphan identities Find cloud admin accounts outside governance, API tokens in code repositories, and local system accounts with unclear ownership, then either assign control or remove them from production use.

Key takeaways

• The article shows that identity compromise often begins with subtle account and session changes rather than a single obvious intrusion event.
• The scale problem is real: attackers can hide inside dormant accounts, weak MFA paths, and unmanaged machine identities long enough to operate below the radar.
• Continuous discovery, behaviour-based monitoring, and machine identity ownership are the controls most likely to reduce exposure before persistence becomes impact.

Key terms

• Identity compromise: Identity compromise is when an attacker gains or abuses a legitimate account, token, or session rather than forcing entry through a separate malware-only path. It matters because trusted identity activity often blends into normal operations, making the intrusion harder to spot and harder to contain.
• Shadow account: A shadow account is an identity that exists and can be used, but is not properly governed, owned, or visible to the systems that are supposed to control it. These accounts create unmanaged trust paths and are often the easiest place for attackers to hide persistence or privilege abuse.
• Machine identity: A machine identity is a non-human credential such as a service account, API token, certificate, or workload identity used by software and infrastructure. In practice, it needs the same accountability as a human account, but its activity patterns, ownership, and lifecycle controls are usually much less visible.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Hydden: Continuous Identity Security is Not Optional. Read the original.