A common sign is a mismatch between identity provider logs and the logs of downstream services. If a service accepts a valid assertion but the upstream IAM system shows no corresponding activity, that discrepancy may indicate forged or replayed credentials. Other signals include unusual device enrolment, unexpected remote access patterns, and access that mirrors normal user behaviour too closely.
Identity clues that distinguish persistence from ordinary malware
When persistence is being maintained through identity systems, the signal is often a control-plane mismatch rather than an endpoint-only one. The attacker may not need resident malware if they can reuse tokens, replay assertions, abuse federation, or keep a trusted account path alive after the original compromise point is gone.
That means the strongest indicators usually sit in authentication, session, and access telemetry. Look for valid logins without the expected upstream enrolment or challenge activity, token or assertion use that appears “clean” to the downstream service but has no matching lifecycle event, and remote access that keeps working even after endpoint remediation or password resets.
- Identity provider activity does not line up with downstream service access.
- Access continues after password resets, device clean-up, or endpoint rebuilds.
- New devices, MFA methods, or enrolment paths appear without a normal change record.
- Remote access patterns stay stable and human-like, even when the underlying host should no longer be trusted.
In practice, this is why identity-focused investigations matter even when malware was initially present. A host can be cleaned while the attacker’s standing access survives in sessions, federated trust, app credentials, or over-privileged accounts.
The identity side of persistence is the one that survives host recovery. If your evidence only explains how code ran on an endpoint, but not why access still exists after remediation, you have not finished the investigation.
Why identity persistence often outlives the initial compromise
Identity-based persistence is attractive because it can blend into normal business activity. A forged or replayed assertion, stolen session token, or compromised application credential can be accepted by downstream systems as legitimate, especially when the service trusts the identity layer more than the device or host that presented the request.
That is also why this class of persistence is easy to miss in endpoint-centric reviews. A clean workstation does not prove the account, token, federation trust, or service credential is clean. The attacker may simply move from malware delivery to trusted access reuse.
NHI Mgmt Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a useful reminder that access paths can persist independently of malware. The practical lesson is to correlate identity activity with service acceptance, not just with endpoint detections.
For deeper context on how identity compromise becomes real-world persistence, see 52 NHI Breaches Analysis and Microsoft OAuth Breach, both of which illustrate how trusted identity paths can sustain access after the initial compromise vector changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Persistent access here often relies on stolen or replayed identity material. |
| NHI-03 — Identity Lifecycle and Offboarding | Lingering access after cleanup points to failed revocation or incomplete offboarding. | |
| NHI-07 — Identity Visibility and Discovery | The main clue is a log mismatch between identity systems and consuming services. | |
| Recommendation — Rotate exposed secrets and revoke any credential or token that still validates unexpectedly. Revoke stale access paths and verify removal across identity providers and downstream services. Correlate identity events with service logs to detect forged, replayed, or orphaned access. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Persistent identity abuse is found through ongoing telemetry correlation and anomaly detection. |
| Recommendation — Monitor identity and service telemetry together to spot access that persists after remediation. | ||
| CIS Controls v8 | 6 — Access Control Management | Unexpected persistence is an access-control failure, not only a malware issue. |
| Recommendation — Review and remove standing access that remains valid after resets, rebuilds, or offboarding. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers may keep access by abusing legitimate accounts and tokens instead of malware alone. |
| T1550 — Use Alternate Authentication Material | Replay and theft of tokens or assertions can sustain access without endpoint malware. | |
| Recommendation — Hunt for legitimate account use that continues beyond the expected lifecycle or trust boundary. Investigate alternate authentication material and invalidate any reused tokens or assertions. | ||
| NIST SP 800-63 | IAL — Identity Proofing | Unusual enrolment or device registration can indicate compromise of the identity process itself. |
| AAL — Authenticator Assurance Level | Assurance gaps help explain how access remains possible after endpoint remediation. | |
| Recommendation — Validate enrolment and proofing evidence before trusting new devices or access methods. Require stronger authenticators for sessions that must resist replay and token abuse. | ||
Practitioner Guidance
What to verify: Test whether the suspicious access can be explained by a normal authentication and authorisation path end to end. If the downstream service sees a valid identity event but the upstream identity provider, MFA, device registration, or token issuance trail does not, treat that as a high-priority persistence signal rather than an anomaly to file away.
Decision rule: If access survives password rotation, endpoint rebuilding, or malware cleanup, assume the persistence mechanism is identity-based until proven otherwise. Prioritise session revocation, token invalidation, federated trust review, and device-enrolment scrutiny before spending time on additional host triage.
What practitioners underestimate: Attackers often try to look boring. Access that mirrors normal user timing, source patterns, and service usage can still be malicious if the identity lifecycle evidence is missing or inconsistent. That is why quiet persistence can be more dangerous than noisy malware, it is harder to notice and easier to retain.
Practitioner takeaway: The key question is not “did we remove the malware?” but “what trusted identity path still allows access?” If you cannot answer that with logs and lifecycle evidence, persistence may still be active.
Related resources from NHI Mgmt Group
- What are the signs that password sync between identity systems is creating an unsafe exposure?
- What are the signs that identity security controls are failing to prevent malicious access with compromised credentials?
- How should organisations operationalize GDPR access and erasure requests through identity systems?
- What breaks when attackers gain access through impersonation rather than malware?
