Warning signs include unexpected password changes, login failures from unfamiliar locations, unexplained recovery requests, missing messages, or account settings that were altered without approval. If the exposed service also stores payment details or personal profile data, monitor for fraudulent purchases, new linked devices, and suspicious account recovery activity that may signal takeover attempts.
When takeover is already underway, the signals tend to cluster
A breached account often looks normal at first, but attacker control usually leaves a trail. The most reliable clues are not a single odd event, but a pattern: changes to credentials, recovery paths, login geography, linked devices, or stored content that the real user did not initiate. The faster those signals appear together, the more likely the account is already being used operationally.
One useful way to read the evidence is to separate access signals from account-state signals. Access signals include failed or unfamiliar sign-ins, repeated resets, and new sessions that do not fit the owner’s normal pattern. Account-state signals include altered passwords, recovery email or phone changes, new forwarding rules, deleted messages, or profile edits that expand attacker persistence.
When the account is tied to commerce, communications, or cloud services, the impact can widen quickly. Fraudulent purchases, new trusted devices, changed security settings, or unexplained authorization prompts may indicate the attacker is moving from initial access to durable control. If the account also exposes personal data, payment methods, or downstream integrations, the compromise may be broader than the mailbox or login itself.
What attackers usually change first
Attackers generally try to make the account easier to keep and harder to recover by the owner. That often means changing the password, adding or swapping recovery methods, creating session persistence through remembered devices, or modifying account settings that reduce visibility. In email and collaboration tools, hidden forwarding, inbox rules, and delegated access are especially important because they let an intruder watch activity without staying visibly logged in.
Missing messages, abrupt settings drift, or security alerts that cannot be explained by the user are often stronger indicators than a single failed login. A real owner typically notices loss of access, unexpected prompts, or content that disappears from the account. In contrast, an attacker wants to preserve the session long enough to extract data, approve transactions, or lock the user out only after the account has been monetised.
If there are linked payment instruments or app integrations, treat new device enrolment and recovery changes as high-value indicators. Those are often the bridge between simple account access and abuse of the wider trust the account already holds with vendors, services, or contacts.
How to judge whether the account is still at risk
The key question is not only whether the account was breached, but whether the attacker still controls any active path back into it. A compromised password may be less important than an unchanged recovery channel, a valid session token, or a trusted device the attacker can reuse. That is why signs of control can remain even after the password is reset.
If the same account can still receive password resets, approve device challenges, or forward sensitive content, the risk remains active. Likewise, if the attacker already changed the recovery email, phone number, or notification settings, the owner may regain partial access without actually removing the intruder. The control problem is therefore broader than authentication alone, it is also about restoring ownership of recovery and session paths.
For that reason, practitioners should look for evidence of both compromise and persistence. A single login anomaly may be transient. Multiple changes to state, recovery, and content usually indicate the attacker has moved past opportunistic access and into ongoing use of the account.
Risk and Threat Considerations
The main risk is false reassurance after the obvious login issue has been fixed. An attacker can keep control through active sessions, recovery settings, forwarding rules, trusted devices, or linked applications even when the password has been changed. That creates a window for continued data theft, fraud, and lateral abuse through the account’s trusted relationships.
Failure mechanism: The intruder preserves one or more durable access paths, such as session tokens, recovery mechanisms, or delegated access, so the owner regains partial visibility without fully evicting the attacker.
Impact: The account can continue to leak messages, approve transactions, reset other accounts, or be used to impersonate the owner until every attacker-controlled path is removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 — Credential Access | Account takeover signs often stem from credential theft and reuse. |
| Recommendation — Correlate login anomalies with credential-access techniques and search for persistence paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Reset, recovery, and session hygiene determine whether attacker access is removed. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Suspicious logins, settings changes, and recovery events require review and correlation. | |
| Recommendation — Rotate authenticators and revoke exposed sessions and recovery paths immediately. Review account activity logs for anomalous sign-ins, settings drift, and recovery actions. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Recovery, authenticator, and session assurance are central to confirming account control. |
| Recommendation — Apply identity assurance checks before restoring access or re-enabling recovery. | ||
| CIS Controls v8 | 5 — Account Management | Compromised accounts require inventory, review, and removal of unauthorized access paths. |
| Recommendation — Inventory affected accounts and disable any unauthorized or stale access paths. | ||
Practitioner Guidance
What to prioritise: Treat credential changes, recovery changes, and trusted-device additions as more important than a single failed login. If any one of those exists alongside altered content or missing messages, assume the account may still be live in attacker hands.
What to verify: Confirm that password reset, recovery email or phone, session tokens, device trust, forwarding rules, and connected apps all belong to the legitimate owner. Do not trust the account until each persistence path has been reviewed and re-established.
Practitioner takeaway: The deciding factor is not whether the breach happened, but whether any control channel that can re-enter the account still belongs to the attacker.
Related resources from NHI Mgmt Group
- How should teams respond when a service account token is exposed?
- What happens when an attacker uses a compromised Global Administrator account to extend Azure control?
- What are the signs that a support system access control failure is already underway?
- What are the signs that a malicious OAuth app may already be operating in a developer account?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
