--- title: "Identity threats in cyber security: the attacks on your logins and how to stop them" canonical: https://www.grcmana.io/blog/identity-threats published: 2023-10-04 updated: 2026-10-22 authors: ["Harry West"] --- # Identity threats in cyber security: the attacks on your logins and how to stop them ## Key takeaways Identity threats use a legitimate identity, such as a stolen password, a hijacked session or an abused privilege, rather than a technical flaw. This list covers eight, from credential stuffing and MFA fatigue to service-desk resets, orphaned accounts, non-human identities and OAuth access. Phishing-resistant MFA, least privilege and joiner-mover-leaver close most of them, and each control should leave a record a buyer or auditor can check. - **Password spraying** — The NCSC defines password spraying as trying a small number of commonly-used passwords against a large number of accounts. A deny list, throttling and failed-login alerts defend against it. - **Prompt fatigue attack** — Also called prompt bombing: the NCSC describes a user bombarded with MFA approval prompts until they mistakenly approve the attacker's sign-in request. Challenge-based apps therefore give only partial phishing resistance. - **FIDO2 MFA** — The NCSC ranks FIDO2 credentials, on trusted devices or roaming security keys, first among MFA types because they provide guessing resistance, phishing resistance and theft resistance. - **Service identity** — NCSC zero trust guidance says a service should have its own unique identity and be granted the minimum privileges necessary to function correctly, rather than borrowing a staff account. Your enterprise prospect's security questionnaire has reached the access control section. It asks whether MFA is enforced everywhere, how admin access is controlled and how fast leavers lose access. Each of those questions exists because of a specific attack. This list covers the identity threats in cyber security behind them, for founders and engineering leads at UK B2B SaaS firms facing a questionnaire or an ISO 27001 or SOC 2 audit. Identity threats are attacks that use a legitimate identity, such as a stolen password, a hijacked session or an abused privilege, rather than a technical flaw. Most start with credentials. Phishing-resistant MFA, least privilege and prompt removal of leavers' access close most of them. Each item passed one test: it is an attack that a customer questionnaire, or an ISO 27001 or SOC 2 auditor, checks through an identity control. Phishing in general and insider threats are separate topics and sit outside this list, except where an attacker talks their way through a password reset. The numbers explain why buyers ask. The UK government's [Cyber security breaches survey 2025/2026](https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026) found that 65% of medium businesses identified a breach or attack in the previous 12 months. Across all UK businesses, only 47% had any two-factor authentication for networks or applications. ## What are the most common identity threats? The most common identity threats fall into three groups: attacks that get past passwords and MFA, attacks that abuse how accounts are issued and removed, and attacks on identities that are not people, such as service accounts and connected apps. The table lists all eight, with the control and the evidence a customer or auditor will ask for. | Threat | How it works | The control | The evidence to show | ISO 27001 reference | | --- | --- | --- | --- | --- | | 1. Credential stuffing | Passwords leaked from other services are tried on your logins | MFA on every internet-facing login, plus a password manager | A report showing MFA enforced for every user, with no exclusions | A.5.17, A.8.5 | | 2. Password spraying | A few common passwords are tried across many accounts | A password deny list, throttling and alerts on failed logins | Password policy settings and one example alert with its ticket | A.5.17, A.8.5 | | 3. MFA fatigue | Repeated push prompts until a user approves one | Phishing-resistant MFA, starting with administrators | The authentication methods policy and a register of admin keys | A.8.5 | | 4. Session and token theft | A stolen session cookie or token stands in for the login | Phishing-resistant MFA, trusted devices and session revocation | The device access policy and a runbook with a revocation step | A.8.5 | | 5. Service-desk resets | A caller persuades the service desk to reset a password or MFA | Verified identity before any reset, with a second approver for admins | The written reset procedure and sampled reset tickets | A.5.17 | | 6. Orphaned and over-privileged accounts | Leavers keep access, or users hold more access than the role needs | Joiner-mover-leaver, separate admin accounts and access reviews | Leaver tickets matched to the HR list, and signed access reviews | A.5.16, A.5.18, A.8.2 | | 7. Non-human identities | Service accounts and API keys hold broad, long-lived access | An inventory with owners, least privilege and rotation | The register showing owner, scope and last rotation date | A.5.16, A.5.17, A.8.2 | | 8. OAuth and third-party access | A connected app or supplier holds a token to your data | Admin approval for apps, an approved list and periodic review | The consent setting and a reviewed register of connected apps | A.5.15, A.5.19 | A control you cannot evidence is, to a buyer's security team, a control you do not have. ## How do attackers get past passwords and MFA? Attackers get past passwords by reusing leaked ones or guessing common ones. They get past weaker MFA by wearing users down with prompts or by stealing the session that MFA created. NCSC guidance ranks FIDO2 credentials as the strongest type of MFA because FIDO2 resists guessing, phishing and theft. ### 1. Credential stuffing **What it is.** Attackers take username and password pairs leaked from breaches of other services and try them on your logins. [MITRE ATT&CK](https://attack.mitre.org/techniques/T1110/004/) describes the technique as taking advantage of "the tendency for users to use the same passwords across personal and business accounts". **When it matters.** Whenever a login is reachable from the internet with a password alone: email, the code repository, the cloud console and your own product's admin panel. **What to do.** Enforce MFA on every internet-facing login, and give staff a password manager, which the [NCSC password guidance](https://www.ncsc.gov.uk/collection/passwords/updating-your-approach) recommends "for secure storage wherever appropriate". Our guide to [Annex A 5.17 authentication information](https://www.grcmana.io/vault/iso-27001/annex-a-5-17-authentication-information) covers the policy side. For evidence, export the MFA enforcement report and show that no user is excluded. ### 2. Password spraying **What it is.** The attacker tries a few common passwords against many accounts, staying under lockout limits. The NCSC defines password spraying as "using a small number of commonly-used passwords in an attempt to access a large number of accounts". **When it matters.** Wherever users choose their own passwords and a service still accepts a password alone. The NCSC warns that legacy protocols often skip MFA, naming "legacy email, file transfer, and remote management interfaces" as common culprits. **What to do.** Block common passwords with a deny list, use throttling or lockout, and alert on failed logins spread across many accounts. Disable legacy protocols that ask only for a password. For evidence, keep the password policy settings, the legacy protocol setting and one example alert with the ticket it raised. ### 3. MFA fatigue **What it is.** With a valid password in hand, the attacker triggers push prompts until the user approves one. The [NCSC](https://www.ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/why-mfa-matters) calls this the push notification fatigue attack, "where a user is bombarded with approval prompts until they mistakenly approve the attacker's sign-in request". **When it matters.** Wherever MFA relies on a simple approve or deny prompt. NCSC guidance says challenge-based apps provide "only partial phishing resistance" because of this attack. **What to do.** Move administrators first, then everyone else, to phishing-resistant MFA such as FIDO2 security keys or passkeys on managed devices. Where push prompts remain, MITRE recommends replacing "simple push or one-click" approval with a code the user types from the login screen. Our [Annex A 8.5 secure authentication](https://www.grcmana.io/vault/iso-27001/annex-a-8-5-secure-authentication) guide covers what an auditor checks. For evidence, show the authentication methods policy and the register of keys issued to administrators. A push prompt approved out of habit is not a second factor. ### 4. Session and token theft **What it is.** Instead of the password, the attacker steals the session cookie or token issued after a good login. A look-alike login page or malware on the device is the usual route. [MITRE ATT&CK](https://attack.mitre.org/techniques/T1539/) notes that a stolen session cookie gives access "as an authenticated user without needing credentials". **When it matters.** Once MFA is in place, because session theft skips the login entirely. The NCSC warns that attackers "often use a stolen session credential to promptly find and steal sensitive data before they are detected". **What to do.** Phishing-resistant MFA removes the easiest route, a look-alike page that relays the session to the attacker. Limit sensitive services to trusted devices. Make sure a suspected stolen session is revoked and the account and device are checked. For evidence, keep the device access policy and an incident runbook with a session revocation step. ## How do attackers abuse the way accounts are managed? Attackers abuse account management by persuading the service desk to reset a password or MFA method, or by using accounts that should no longer exist or hold more access than the role needs. Both are process failures, not technical ones. That is why auditors test them through tickets and access reviews, not system settings. ### 5. Service-desk resets **What it is.** An attacker calls or messages the IT service desk, poses as an employee and asks for a password or MFA reset. After the 2025 attacks on UK retailers, the [NCSC](https://www.ncsc.gov.uk/blog-post/incidents-impacting-retailers) urged organisations to review "how the helpdesk authenticates staff members credentials before resetting passwords, especially those with escalated privileges". **When it matters.** Whenever a reset can be granted on details an attacker could find online, such as a name, job title or manager's name. It matters most for administrators, whose resets the NCSC singles out. **What to do.** Write a reset procedure that confirms identity through a channel the caller does not control, such as a call back to the number held in the HR record. Require a second approver for any administrator reset. For evidence, show the procedure and a sample of reset tickets that record the verification step. If a phone call can reset MFA, your MFA is only as strong as the service desk script. ### 6. Orphaned and over-privileged accounts **What it is.** Orphaned accounts belong to people who have left or changed role. Over-privileged accounts hold more access than the job needs, including everyday accounts with admin rights. [MITRE ATT&CK](https://attack.mitre.org/techniques/T1078/) notes that attackers abuse inactive accounts because "the original account user will not be present to identify any anomalous activity". **When it matters.** After every leaver, role change and contractor exit, and in growing teams where access is granted quickly and seldom removed. **What to do.** Run joiner-mover-leaver (JML) as one process triggered by HR, with access removed on the leaver's last day. Our [Annex A 5.16 identity management](https://www.grcmana.io/vault/iso-27001/annex-a-5-16-identity-management) guide sets out the JML records auditors expect. Keep admin rights on separate accounts and review access on a fixed cycle; our guide to [Annex A 8.2 privileged access rights](https://www.grcmana.io/vault/iso-27001/annex-a-8-2-privileged-access-rights) covers the rules auditors test. For evidence, match leaver tickets to the HR leavers list with removal dates, and keep signed access reviews. ## Which identities do attackers target beyond your staff? Beyond staff accounts, attackers target non-human identities, such as service accounts, API keys and deployment tokens, and the third-party apps and suppliers connected to company data. These identities rarely use MFA, often hold broad access and are easy to forget. A list of them, each with a named owner, is the first control. ### 7. Non-human identities **What it is.** Service accounts, API keys, deployment credentials and other machine identities that let software act inside your systems. [NCSC zero trust guidance](https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles/know-your-user-service-device-identities) says a service "should have its own unique identity and be granted the minimum privileges necessary to function correctly". **When it matters.** Wherever software signs in to other software. [MITRE ATT&CK](https://attack.mitre.org/techniques/T1528/) notes that build and deployment (CI/CD) pipelines "will often use API tokens to authenticate to other services", and that attackers who steal such tokens may "access data and perform actions with the permissions of these accounts". **What to do.** Keep a list of non-human identities, each with an owner, purpose and scope. Give each service its own identity, not a shared staff login. Prefer short-lived, narrow tokens to long-lived keys. The NCSC recommends "modern service authentication methods, such as certificate-based credentials". For evidence, show the register with owner, scope and last rotation date. ### 8. OAuth and third-party access **What it is.** A user grants a third-party app an OAuth token to company email, files or code, or a supplier keeps standing access to your environment. [MITRE ATT&CK](https://attack.mitre.org/techniques/T1550/001/) notes that once a token is granted to a malicious application, it "can potentially gain long-term access to features of the user account". **When it matters.** Whenever users can approve apps themselves, and whenever a supplier integration or support account can reach customer data. **What to do.** Make an admin approve each new app connection, and keep an approved list. MITRE calls this "forcing administrative consent". Review connected apps and supplier accounts on the same cycle as staff access, and remove tokens when a relationship ends. [Annex A 5.15 access control](https://www.grcmana.io/vault/iso-27001/annex-a-5-15-access-control) gives the rules this review sits under. For evidence, show the consent setting and the app register with review dates. ## How to use this list Work through the list in three passes. First, MFA everywhere, starting with administrators and moving to phishing-resistant methods. Second, privileged access: separate admin accounts, the reset procedure and non-human identities. Third, access reviews and joiner-mover-leaver, so that access granted is also access removed. MFA comes first because items 1 to 4 all start at the login. The [NCSC](https://www.ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/why-mfa-matters) is clear that "any implementation of MFA is still superior to reliance on passwords alone", so switch on what you have today and strengthen it later. Privileged access comes second because a compromised admin or service account does the most damage. Access reviews come third because they keep the first two passes true as people join, move and leave. We recommend writing each control into your access control policy, with an owner and the record it leaves. Our [access control policy template](https://www.grcmana.io/vault/templates/access-control-policy) gives you the structure. Eight controls, each with a record, is a short list to own, and it gives you an answer to each identity question before the buyer asks it. ## Frequently asked questions ### What is an identity-based attack? An identity-based attack uses a real account's credentials, session or permissions to get in, rather than exploiting a software flaw. Because the activity looks like a legitimate user, it is harder to spot. MITRE notes that attackers using valid accounts may avoid malware "to make it harder to detect their presence". ### Does MFA stop account takeover? MFA stops most password-only attacks, such as credential stuffing and password spraying, but weaker methods can be beaten. The NCSC describes one-time code interception and prompt bombing as two ways round them. Phishing-resistant FIDO2 MFA closes those routes, while session theft and service-desk resets need their own controls. ### What is identity threat detection and response (ITDR)? Identity threat detection and response (ITDR) means monitoring identity systems for signs of attack and acting on what you find. [MITRE ATT&CK](https://attack.mitre.org/techniques/T1078/) lists signals to watch for in identity provider logs, such as "impossible travel, risky sign-ins, and multiple MFA attempts or failures". The NCSC adds that a suspected stolen session should trigger a policy that blocks its use. Whether you buy a tool or use existing sign-in logs, the questionnaire asks the same thing: do you detect and act on suspicious logins? ### Which accounts should get phishing-resistant MFA first? Administrators come first. The NCSC's example is that all IT administrators get "a hardware security key that must be used when accessing administrative interfaces". Next come users who reach sensitive data, since the NCSC says "all user accounts with access to sensitive data should have MFA enforced".