Look for access to unfamiliar applications, abnormal login timing, unusual source hosts, unexpected network communication and workflow actions that do not match the identity’s normal purpose. These signals matter because a machine can remain authenticated while its activity pattern shifts into something risky or malicious.
What to look for when a machine identity stops behaving like itself
A machine identity is hard to trust once its activity stops matching the role it was issued for. The most useful signals are behavioural drift: new applications, odd login times, unfamiliar source systems, and actions that do not fit the normal workflow. Those changes matter because the identity can still authenticate successfully while its access is being used in a risky or malicious way.
For a broader view of machine identity patterns, the Ultimate Guide to NHIs and the Human vs Non-Human Identity comparison both help frame what “normal” should look like across ownership, lifecycle, and access behaviour.
Which activity patterns are most suspicious?
The strongest indicators are usually the ones that show the identity is being used outside its intended operating envelope. Access to unfamiliar applications, APIs, repositories, or admin surfaces is a classic warning sign, especially when the identity normally has a narrow purpose. Abnormal login timing, unusual source hosts, and new geographic or network origins are also important because they suggest either compromise or a change in how the identity is being used.
Unexpected workflow actions are equally important. If a service account suddenly creates resources, modifies permissions, reads data it never touched before, or triggers automation at odd points in the process, the problem is not just “different behaviour”, it is a possible trust break. That is why practitioners should treat a deviation from purpose as a security signal, not just an operational anomaly.
The Service Account Security Guide and Top 10 NHI Issues are useful follow-ons because they connect suspicious behaviour to the common failure patterns that make machine identities hard to govern.
How do you separate normal change from trust failure?
Not every new behaviour is malicious. A machine identity may change because the application was redeployed, the environment was replatformed, or a new integration was legitimately added. The test is whether the change is explainable through approved change control, whether the new behaviour fits the identity’s assigned purpose, and whether the access path and source are expected.
When the explanation is weak or incomplete, trust should drop quickly. A machine identity does not need to be “compromised” in the narrow sense to become untrustworthy. It is enough that ownership is unclear, the credential lifetime is too long, the observed activity no longer matches the declared function, or the identity is being used from systems that were never meant to hold it.
For identities that rely on certificates or workload credentials, Machine Identity, PKI and Certificate Lifecycle Guide and Cloud Workload Identity Guide help distinguish lifecycle-driven changes from suspicious drift.
Risk and Threat Considerations
Untrusted machine identities are dangerous because they often retain valid authentication while their behaviour becomes the attack surface. If an attacker steals a token, key, or certificate, or if a legitimate identity is misused, the access can blend into normal traffic long enough to reach sensitive systems, move laterally, or perform actions that look operational until the impact is visible.
Failure mechanism: Detection fails when teams monitor only authentication success and ignore purpose, source, timing, and action patterns. A machine identity with excessive privilege or a long-lived secret can keep working after compromise, so the warning signs are usually behavioural rather than login failures.
Impact: The result can be unauthorized data access, unexpected infrastructure changes, privilege abuse, or persistence that is harder to spot than human account compromise because the activity is automated and often appears routine.
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 SP 800-53 Rev 5 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-02 — Secret Leakage | Stolen or exposed secrets often drive untrustworthy machine-identity behaviour. |
| NHI-05 — Overprivileged NHI | Unexpected actions often indicate privilege beyond the identity's intended purpose. | |
| NHI-07 — Long-Lived Secrets | Persistent credentials let compromised machine identities keep behaving normally. | |
| Recommendation — Rotate exposed secrets and investigate anomalous use paths immediately. Reduce privileges to the minimum required for the identity's role. Replace long-lived credentials with shorter-lived, managed alternatives. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Anomalous source, timing, and action patterns require review of audit evidence. |
| IA-5 — Authenticator Management | Machine-identity trust depends on controlling the credentials and authenticators it uses. | |
| AC-6 — Least Privilege | Unexpected actions are easier to contain when machine identities have minimal access. | |
| Recommendation — Review audit trails for deviations from the identity's normal activity pattern. Enforce lifecycle controls for machine credentials and rotate them on compromise signals. Restrict machine identities to only the access needed for their approved function. | ||
| NIST Zero Trust (SP 800-207) | Never trust, verify | Machine identities require continuous verification of access context and behaviour. |
| Recommendation — Revalidate each request against identity, context, and purpose before granting access. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers commonly abuse valid machine identities rather than breaking authentication. |
| Recommendation — Hunt for valid-account abuse when machine behaviour diverges from its baseline. | ||
Practitioner Guidance
What to verify: Compare the observed action set against the identity’s declared purpose, owner, approved source systems, and normal time window. If any one of those no longer fits, treat the identity as suspect until the deviation is explained.
What to measure: Track new application targets, first-seen source hosts, off-hours activity, and workflow actions that are outside the identity’s historical baseline. A rising rate of “new but approved” activity is a sign that governance, not just detection, needs attention.
Decision rule: If a machine identity can reach production systems, then unexplained behaviour should trigger credential review, source validation, and privilege review before you assume the identity is safe because it still authenticates.
Practitioner takeaway: Trust for machine identities is behavioural as much as cryptographic, so the most important question is not whether the identity still works, but whether its current actions still match its intended role.
Related resources from NHI Mgmt Group
- What are the signs that machine identity governance is no longer keeping up?
- What are the signs that delegated trust in machine identity workflows is getting out of control?
- What are the signs that legacy identity governance is no longer keeping pace with cloud and SaaS growth?
- What are the signs that machine identity controls are failing in a cloud environment?