Account Compromise

Expanded Definition

Account compromise is not just a login failure or a password reset event. It is a security state in which an attacker has obtained enough valid access to operate as the legitimate identity, often by stealing credentials, hijacking a session, abusing recovery flows, or taking over a federated account. In identity security terms, the key issue is trust inversion: the organisation continues to treat the account as genuine while the attacker uses it for reconnaissance, data access, fraud, or privilege escalation. Guidance varies across vendors on whether short-lived token theft, consent abuse, and session replay are classified separately or folded into account compromise, so definitions should be read carefully. In practice, the concept spans user accounts, service account, and increasingly non-human identities where secrets or tokens are exposed. For a control-oriented reference point, NIST SP 800-53 Rev 5 Security and Privacy Controls maps the surrounding authentication, access control, and incident response expectations that help constrain takeover and contain abuse. The most common misapplication is treating account compromise as a single password problem, which occurs when organisations ignore session theft, MFA bypass, and downstream privilege use.

Examples and Use Cases

Implementing detection and response for account compromise rigorously often introduces more friction in authentication, session validation, and user verification, requiring organisations to weigh faster access against stronger abuse resistance.

• A phishing email captures a user password and the attacker logs in from a new location, then searches mailbox data for payment instructions and sensitive attachments.
• A help desk workflow is abused to reset a password after weak identity verification, allowing the attacker to reach internal portals with the victim’s privileges.
• A stolen session token is replayed from another device, bypassing the password entirely and making the activity look like normal authenticated use.
• An attacker exploits an OAuth consent prompt to obtain persistent access without ever learning the user’s password, a pattern that is increasingly discussed in modern identity abuse reporting, including the Anthropic — first AI-orchestrated cyber espionage campaign report.
• A service account secret is exposed in code or logs, letting an attacker automate access to APIs, data pipelines, or cloud resources as if the account were legitimate.

Why It Matters for Security Teams

Account compromise matters because it collapses the boundary between approved and malicious activity. Once an attacker is inside a legitimate identity, many perimeter tools lose visibility and routine behaviour can mask high-risk actions such as mailbox rules creation, privilege escalation, token minting, or data exfiltration. For security teams, the term is operationally useful because it forces investigation across authentication logs, device context, privilege changes, and unusual access patterns rather than focusing only on initial entry. It also has a direct identity and NHI security angle: compromised human accounts and compromised non-human identities often become the first foothold for lateral movement, cloud abuse, and automation at scale. Stronger governance usually means combining MFA, conditional access, session monitoring, secret hygiene, and rapid revocation with detection logic that watches for impossible travel, anomalous consent, and abnormal API use. Security operations also need a recovery path that preserves evidence while disabling the attacker’s path of persistence. Organisations typically encounter the true impact only after data theft, fraudulent payments, or privileged misuse is confirmed, at which point account compromise becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between direct account compromise and SaaS supply chain compromise?
• Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?
• What is the difference between developer account compromise and secret compromise in CI/CD?
• Who is accountable when weak MFA leads to account compromise?