What breaks when identity events are not visible during an ICT incident?

The organisation loses the ability to classify scope, prove root cause, and produce timely regulatory reporting. If service account misuse or vendor access abuse is not observable, the incident response process becomes guesswork and recovery slows. DORA’s reporting obligations assume identity telemetry exists and is actionable.

Why This Matters for Security Teams

During an ICT incident, identity telemetry is what turns a vague outage into an explainable security event. If service account activity, vendor access, API key use, or token issuance cannot be seen in real time, teams cannot reliably distinguish compromise from misconfiguration, lateral movement from normal automation, or privilege abuse from routine service behaviour. That directly affects containment, evidence preservation, and regulatory reporting.

This is not a theoretical gap. NHI exposure is already a high-frequency problem: the Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which means most incident teams are starting from partial telemetry. The result is slower scoping, weaker forensics, and more uncertainty when deciding which systems, secrets, and third parties are in play. Guidance from NIST CSF 2.0 reinforces that detection and response depend on asset and identity observability, not just endpoint alerts.

In practice, many security teams discover the absence of identity visibility only after a vendor token, automation account, or CI/CD secret has already been used in ways the logs cannot reconstruct.

How It Works in Practice

Identity events need to be observable at the same speed as the incident itself. That means logging authentication, token minting, secret retrieval, role assignment changes, API key use, federation assertions, and administrative actions across IAM, PAM, SaaS, cloud control planes, and automation platforms. It also means correlating those events with workload context so responders can tell which identity acted, from where, using which trust path, and on behalf of which process or vendor.

For mature environments, the practical model is a mix of centralised logging, immutable retention, and policy-enforced tracing. Security teams often pair SPIFFE-style workload identity, short-lived credentials, and request-time policy evaluation so that each action can be attributed to a specific workload or agent rather than a shared account. That is especially important when response teams need to confirm whether an access token was legitimate, stolen, or replayed.

NHI-focused research at 52 NHI Breaches Analysis shows how frequently compromise patterns involve service accounts and secrets that were not being watched closely enough. In an ICT incident, that kind of visibility determines whether responders can:

• trace the first compromised identity and the path of reuse
• identify vendor or third-party access that remains active
• prove which secrets were exposed and whether they were rotated
• separate legitimate automation from attacker-driven activity

Where possible, incident playbooks should map identity events to systems of record, retention requirements, and reporting thresholds before an event occurs. These controls tend to break down in hybrid estates where legacy directories, SaaS admin consoles, and unmanaged service accounts generate inconsistent logs or no usable correlation IDs.

Common Variations and Edge Cases

Tighter identity telemetry often increases storage, integration, and alert triage overhead, so organisations must balance forensic value against operational noise. Best practice is evolving, but there is no universal standard for how much identity logging is enough for every ICT incident class.

Cloud-native environments usually have the best chance of strong identity observability because control-plane logs, federation events, and workload tokens can be normalised. Legacy infrastructure, outsourced operations, and third-party managed services are harder cases because identity events may sit outside the responder’s tooling or retention window. That is where reporting obligations become fragile: if the organisation cannot reconstruct who accessed what, when, and through which credential path, it cannot confidently establish scope.

For broader incident governance, CISA Secure Software Guidance is useful for thinking about the chain between code, secrets, and runtime behaviour, while the Ultimate Guide to NHIs — Why NHI Security Matters Now is a practical reminder that non-human identities are now too numerous and too privileged to treat as background infrastructure. The main edge case is shared administrative tooling, where a single console action can mask multiple underlying identities and make attribution ambiguous even with good logs.

Related resources from NHI Mgmt Group

• When do incident management tools become part of identity security operations?
• What breaks when SSO trust is too permissive across identity providers?
• Who should revoke a compromised SaaS integration during an incident?
• What breaks when a malicious npm package can read developer secrets during install?