RSAC 2023 showed identity security needs runtime context

At a glance

What this is: This RSAC 2023 recap argues that identity security now depends on runtime context, ITDR, deception, and cloud telemetry rather than authentication alone.

Why it matters: For IAM, NHI, and security teams, it reinforces that compromised identities and workload context must be detected and constrained in real time, not just provisioned correctly.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read SentinelOne's RSAC 2023 recap on identity security, ITDR, and cloud context

Context

Identity security fails when teams assume authentication is the primary control boundary. In practice, attackers often reuse compromised identities, service accounts, and secrets to move laterally after initial access, which means the real problem is runtime abuse of identity, not just login success or failure.

This RSAC recap is a practitioner signal rather than a product story. The useful thread is SentinelOne's emphasis on ITDR, deception, and cloud context enrichment, which points to a broader shift: IAM and NHI governance must account for detection and response after identity is already in play.

Key questions

Q: How should security teams detect identity misuse after authentication succeeds?

A: They should monitor for behavioural anomalies, permission overreach, unusual context shifts, and access to assets that do not match normal job or workload patterns. Authentication success only proves the credential was accepted. Detection has to answer whether the identity is being used in a way that fits its historical scope and entitlement profile.

Q: Why do service accounts and tokens need runtime monitoring?

A: Because valid credentials can still be used maliciously after they are issued. Service accounts and tokens often have broad reach, so defenders need runtime visibility into how they are used, what they touch, and whether the surrounding cloud context makes that use suspicious. Without that, compromise can look like ordinary access.

Q: What do security teams get wrong about identity threat detection and response?

A: They often treat ITDR as a substitute for IAM, when it is actually complementary. IAM decides whether access should exist, while ITDR watches for abuse once access exists. If teams collapse those two functions, they miss the difference between legitimate access and legitimate access being weaponised.

Q: What is the difference between ITDR and IAM governance?

A: IAM governance manages entitlement, lifecycle, and policy. ITDR focuses on detection and response when those controls are bypassed or abused. The two are not interchangeable. Identity governance tells you what should happen, while ITDR tells you when identity behaviour has moved outside the expected boundary.

Technical breakdown

Why identity threat detection and response fills the gap after login

Identity Threat Detection and Response, or ITDR, focuses on abuse that happens after authentication succeeds. Traditional IAM can verify who or what is allowed in, but it does not necessarily show whether the identity is being used normally, whether credentials were stolen, or whether access is being chained into lateral movement. ITDR adds behavioural and contextual telemetry so defenders can see misuse of accounts, tokens, and sessions as active threats rather than normal access events. That matters because many real intrusions begin with valid identity material, not broken passwords or failed sign-ins.

Practical implication: monitor for identity misuse patterns, not just authentication failures.

How cloud context enrichment improves workload and identity triage

Cloud context enrichment combines identity activity with configuration, permissions, vulnerability, and infrastructure metadata. In operational terms, that means a security platform can interpret a suspicious action in light of what the workload can reach, what it is allowed to do, and whether the surrounding environment increases blast radius. For NHI governance, this matters because a token or service account is rarely the whole story. The permissions attached to it, plus the runtime state of the environment, determine whether a security event is low risk or a path to compromise.

Practical implication: correlate identity events with permissions and configuration state before triaging severity.

Why deception remains useful against stolen identities

Deception techniques create decoys, traps, or signals that reveal when an attacker is operating with stolen identity material. The value is not in blocking every action, but in turning misuse into a detectable event once an intruder starts exploring accounts, systems, or paths that should never be touched. In identity security, that is especially relevant where access looks legitimate on paper. Deception helps expose the difference between authorised use and adversarial use, which is a persistent challenge when service accounts or compromised employee identities are involved.

Practical implication: place decoys around high-value identity paths to catch post-authentication abuse earlier.

Threat narrative

Attacker objective: The attacker objective is to convert valid identity access into broader environmental reach without triggering conventional authentication controls.

1. Entry occurs when an attacker obtains valid identity material or compromised credentials and uses them to appear legitimate inside the environment.
2. Escalation follows as the attacker pivots laterally, enriches access with cloud and identity context, and expands reach through permissions already attached to the account.
3. Impact occurs when the attacker uses that identity-led access to reach systems, data, or workloads that should have been isolated from the original foothold.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Runtime identity context is now a core control surface, not an optional enhancement. The article's emphasis on cloud context enrichment reflects a wider shift in identity security: access decisions are no longer meaningful unless defenders also understand permissions, configuration, and runtime state. That is especially true for NHI, where service accounts and tokens can be valid while still being dangerous. Practitioners should treat contextual telemetry as part of identity governance, not a separate security stack concern.

Identity Threat Detection and Response is becoming the practical layer between IAM and incident response. IAM establishes who or what should have access, but it does not stop misuse once valid credentials are in hand. ITDR is the control plane for seeing abnormal identity behaviour after authentication, which is where many modern intrusions actually operate. Security teams should assume that identity compromise is a response problem as much as a provisioning problem.

Compromised identity remains the dominant failure mode because attackers prefer legitimate access paths. The NHI security problem is not just secret leakage, but the operational reality that stolen identities let attackers blend into normal activity. That is why visibility, privilege scope, and runtime detection must be managed together. Practitioners should re-centre programmes on whether identity use is observable and containable once it becomes adversarial.

Deception strengthens identity defence when the environment cannot prevent every misuse. The article correctly points to deception as a way to expose attackers who are operating through stolen accounts or service identities. In NHI terms, this is not a replacement for lifecycle control or secret hygiene. It is a way to detect the moment identity trust has been converted into attacker reach, which is where response must begin.

81% of breaches involving compromised identity material, as covered in the 52 NHI Breaches analysis, shows that the industry still underestimates identity-led intrusion paths. That pattern makes runtime detection and context enrichment essential for any serious NHI or IAM programme. The practitioner conclusion is straightforward: if identity is the entry point, identity telemetry has to be the first line of investigation.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why identity-led intrusions so often go undetected until abuse is already underway.
• For deeper breach pattern analysis, see 52 NHI Breaches Analysis for real-world examples of how compromised identities turn into operational impact.

What this signals

Runtime context is becoming the deciding factor in identity security programmes. Teams that only know whether access was granted will keep missing the more important question of whether the identity was used in a way that matched its intended scope. That is why cloud permissions, configuration state, and identity telemetry need to be analysed together.

81% of breaches involving identity compromise, as covered in our 52 NHI Breaches Analysis, shows that detection must start from the identity layer. The programme implication is simple: if you cannot observe identity misuse quickly, you are relying on post-incident forensics rather than live defence.

The operational shift is toward containment based on context, not just account status. That means building workflows that can rapidly distinguish routine access from suspicious identity behaviour across service accounts, tokens, and human accounts alike.

For practitioners

• Correlate identity events with workload context Connect authentication, token use, permission scope, and cloud configuration so analysts can judge whether an identity action is routine or adversarial. This is especially important for service accounts and API keys that have broad but poorly understood reach.
• Separate IAM validation from post-authentication monitoring Use IAM to govern entitlement, then layer detection for misuse patterns such as unusual lateral movement, repeated context switching, or access to decoy assets. Validation alone will not show whether a valid identity has been repurposed.
• Instrument deception around high-value identity paths Place decoys near privileged accounts, secrets stores, and administrative paths that are attractive to intruders. The goal is not broad coverage, but early detection when legitimate identity material starts being used adversarially.
• Review machine and human identity telemetry together Look for common attacker behaviours across employee accounts, service accounts, and tokens. The same misuse pattern often appears across all three, and siloed monitoring makes it easier to miss the escalation path.

Key takeaways

• Identity security is shifting from access validation to runtime misuse detection, because valid credentials are now a common attacker entry point.
• The practical challenge is visibility, since many organisations still lack full insight into service accounts and their actual privilege use.
• Teams need combined IAM, ITDR, and deception coverage if they want to detect and contain identity-led intrusions before lateral movement succeeds.

Key terms

• Identity Threat Detection and Response: Identity Threat Detection and Response is the practice of spotting and investigating misuse of identities after access has been granted. It combines behavioural analysis, identity telemetry, and response workflows to detect stolen credentials, suspicious sessions, and abnormal privilege use across human and non-human identities.
• Cloud Context Enrichment: Cloud context enrichment means adding permissions, configuration, workload, and vulnerability data to identity events so they can be interpreted correctly. Without that context, a valid login or token use can look normal even when it creates real exposure or indicates active attacker movement.
• Deception Technology: Deception technology uses decoys, traps, or false paths to expose attackers who are already operating inside an environment. In identity security, it is useful because stolen credentials often blend into normal access patterns, so a decoy can reveal adversarial intent that authentication controls will not catch.

What's in the full article

SentinelOne's full recap covers the operational detail this post intentionally leaves for the source:

• Partner talk track details from RSAC 2023, including the booth sessions and collaboration themes that were only summarised here.
• The ITDR presentation content on deception tactics, including the specific detection logic and use cases discussed at the event.
• The eBPF session details on cloud workload protection, including the runtime observability arguments and architecture discussion.
• The partner integration example showing how cloud context was ingested into the platform during threat enrichment.

👉 SentinelOne's full recap includes the booth talks, partner demos, and runtime security session details from RSAC 2023.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.