Most serious intrusions now succeed because an attacker logs in as someone the organisation already trusts, not because they break through a technical defence. This briefing is for directors, chief executives, audit and risk committee members and CISOs who need to understand identity threat in business terms: why stolen and abused logins have become the main route into the business, what phishing-resistant authentication and identity threat detection and response (ITDR) actually buy, and how to judge whether management's answers hold up. It stays at board level. The attack techniques are explained in the Top 10 Identity Attacks and the detection discipline in the ITDR Guide.
The risk in one paragraph
Every person, supplier, application and automated process in the organisation reaches systems through an identity: a username and password, a token, a key or a session cookie. Attackers have learned that obtaining one of these is cheaper and quieter than exploiting software. They buy passwords harvested by infostealer malware, phone the help desk pretending to be an employee, flood a user with approval prompts until they accept, or steal a session cookie that has already passed multi-factor authentication. Once inside, they look like a legitimate user, so ordinary security tools see nothing unusual. They then move to the accounts that control everything else: identity provider administrators, cloud tenant owners, backup consoles and the service accounts that connect systems. The damage an identity attack can do is set by two things the board can influence directly: how easily a login can be stolen or faked, and how much of the business one compromised account can reach.
Why this is a board-level issue now
- The largest recent losses began with a login. At Change Healthcare in February 2024 attackers used a stolen credential on a remote access portal that had no multi-factor authentication, deployed ransomware nine days later, and the incident grew into the largest US healthcare data breach reported, affecting 192.7 million people. See the Change Healthcare breach analysis.
- A phone call can defeat a large security budget. In the MGM Resorts incident of September 2023 the attackers' own account describes a call to the IT help desk impersonating an employee, followed by administrator access to identity systems; MGM estimated a negative impact of about $100 million. See the MGM Resorts breach analysis.
- Stolen passwords stay valid for years. In the 2024 Snowflake campaign, attackers logged in to about 165 customer environments with passwords harvested by infostealer malware, some from infections dating back to 2020, because the accounts had no MFA and the passwords had never been rotated. See the Snowflake breach analysis.
- Governments now set the bar at phishing-resistant MFA. US federal policy (OMB M-22-09) requires phishing-resistant MFA for agency staff, contractors and partners and directs agencies to stop supporting SMS, voice, one-time codes and push approvals for routine access. Boards in the private sector are increasingly asked by insurers, customers and regulators why they accept a lower standard.
- The threat is not only human accounts. Service accounts, API keys and OAuth applications usually have no MFA, rarely expire and often hold broad rights. Attackers target them because no person notices when they are misused. See the Board Briefing: NHI Risk.
How identity attacks unfold, in business terms
Boards do not need technique detail, but they do need to recognise the stages, because each one maps to a control that management should be able to evidence.
| Stage | What the attacker does | Business consequence | Control management should evidence |
|---|---|---|---|
| Obtain a credential | Buys infostealer logs, runs phishing pages, reuses leaked passwords | A valid login exists outside the organisation's control | Phishing-resistant MFA everywhere, leaked credential monitoring |
| Bypass the second factor | Floods push prompts, swaps a SIM, relays one-time codes, steals session cookies | Ordinary MFA is defeated without any software flaw | FIDO2 passkeys or certificate-based MFA; short session lifetimes; device-bound sessions |
| Talk past the help desk | Impersonates an employee to reset a password or MFA device | Strong authentication is reset away in minutes | Verified identity checks for resets, call-back procedures, extra checks for privileged users |
| Take control of identity systems | Gains administrator rights in the identity provider or cloud tenant | Attacker can create accounts, change policies and disable protections | Few standing administrators, just-in-time elevation, alerts on admin changes |
| Abuse machine identities | Uses service accounts, API keys and OAuth apps that never prompt for MFA | Long-lived, quiet access that survives password resets | Inventory with owners, rotation, least privilege, monitoring of non-human identities |
| Act on objectives | Steals data, encrypts systems, commits fraud | Outage, notification duties, extortion, reputational harm | Detection and response on identity signals, tested recovery of identity systems |
In MITRE ATT&CK terms these stages include Valid Accounts (T1078), Multi-Factor Authentication Request Generation (T1621), Steal Web Session Cookie (T1539) and Modify Authentication Process (T1556). Management should be able to show which of them its detections cover.
Phishing-resistant MFA: the investment that changes the odds
Not all multi-factor authentication is equal, and "we have MFA" is the most common false comfort in board papers. CISA's guidance on implementing phishing-resistant MFA describes FIDO/WebAuthn as the only widely available phishing-resistant method, with certificate-based (PKI) smart cards also phishing resistant but harder to run. It warns that one-time codes can be phished, that push notifications without number matching are open to push bombing, and that SMS and voice codes are vulnerable to SIM swap and telephone network attacks. CISA's Scattered Spider advisory recommends FIDO/WebAuthn or PKI-based MFA precisely because these methods resist phishing, push bombing and SIM swap.
| Method | Resists phishing pages | Resists push fatigue | Resists SIM swap | Board view |
|---|---|---|---|---|
| SMS or voice code | No | Not applicable | No | Retire for staff and administrators |
| Authenticator app one-time code | No | Not applicable | Yes | Interim only |
| Push approval without number matching | No | No | Yes | Retire |
| Push with number matching | Partly | Yes | Yes | Acceptable interim for general staff |
| FIDO2 security key or passkey | Yes | Yes | Yes | Target for all staff, mandatory for privileged users |
| Certificate-based smart card | Yes | Yes | Yes | Strong where PKI already exists |
The cost is mostly in rollout effort, help desk processes and devices for staff who cannot use phones, not in licences. The order matters: administrators and remote access first, then email and collaboration, then everyone. Phishing-resistant MFA does not stop session cookie theft from an infected device, which is why session controls and detection are the second investment. See the Phishing-Resistant MFA Guide.
ITDR: seeing the attacker who has a valid login
Identity threat detection and response is the discipline of watching identity systems themselves for misuse: impossible travel and unusual sign-ins, sudden MFA device registrations, new administrator role assignments, changes to federation and authentication policy, consent grants to new applications, and service accounts behaving unlike their normal pattern. It closes the gap left by endpoint and network tools, which cannot tell a legitimate login from a stolen one.
- What the board is buying: earlier detection of account takeover and faster containment, measured as time from first suspicious identity event to revoked sessions and reset credentials.
- What it is not: a replacement for strong authentication. Detection reduces how long an attacker stays; phishing-resistant MFA reduces how often they get in.
- Build or buy: large organisations often combine identity provider protections with a SIEM and a dedicated ITDR capability; smaller ones can get most of the value from the identity provider's own risk policies and a managed detection service, provided someone responds out of hours.
- Machine identities count: a detection programme that covers only human sign-ins misses the service accounts and tokens that attackers prefer for persistence.
For evaluation criteria see the ITDR Buyer's Guide.
Five questions for the board to ask
- What percentage of our staff, administrators and remote access paths use phishing-resistant MFA today, and when will it be 100 per cent for administrators? A credible answer gives separate figures for each group and a dated plan, not a single "MFA enabled" number.
- If someone phoned our help desk tonight pretending to be the CFO, what would stop them resetting her MFA? Expect a described verification procedure, extra checks for executives and administrators, and evidence it has been tested.
- How many people and machine accounts can change our identity provider, cloud tenant or backup systems, and how many of those rights are standing? The number should be small, known and falling, with just-in-time elevation for the rest.
- How quickly would we notice and contain an attacker using a valid login, and when did we last prove it? Look for a measured detection and containment time from an exercise or real event in the last 12 months.
- Do we know every service account, API key and third-party application with access to our data, and who owns each one? A good answer includes an inventory, named owners and a rotation and review cycle.
Red flags in management answers
- "We have MFA": without a breakdown by method and population, this usually means SMS or push for most users and exemptions for legacy systems and service accounts.
- "Our help desk follows a script": a script that relies on facts an attacker can find on social media is not identity verification.
- "Only IT has admin rights": ask how many, whether they use separate administrator accounts, and whether those accounts have phishing-resistant MFA.
- "Service accounts are exempt because they cannot do MFA": true, which is why they need compensating controls: restricted locations, short-lived credentials, rotation and monitoring.
- "The vendor handles identity": cloud and SaaS providers secure their platforms; configuring who can log in, with what, remains the customer's responsibility, as the Snowflake campaign showed.
- Metrics that never move: the same MFA coverage figure quarter after quarter suggests nobody owns closing the gap.
What good looks like
| Area | Good practice |
|---|---|
| Governance | A named executive owner for identity risk, identity compromise on the risk register with quantified exposure, board review at least annually |
| Authentication | Phishing-resistant MFA for all administrators and remote access, and a dated plan for all staff; legacy methods retired |
| Help desk and recovery | Verified identity checks for password and MFA resets, stricter rules for privileged and executive accounts, resets logged and reviewed |
| Privileged access | Separate administrator identities, few standing administrators, just-in-time elevation for identity, cloud and backup consoles |
| Machine identities | Inventory of service accounts, keys and OAuth apps with owners, least privilege, rotation and expiry |
| Detection and response | Identity signals monitored around the clock, playbooks to revoke sessions and reset credentials, containment time measured |
| Resilience | A tested plan to recover the identity provider and directory, because nothing else can be restored safely until identity is trusted |
The Identity Security Maturity Model turns this table into five levels for self-assessment.
Where to invest first
- Privileged and remote access: phishing-resistant MFA for every administrator, every remote access path and every identity provider and cloud console. This removes the shortest route from one stolen password to control of the business.
- Help desk verification: a reset process that an impersonator cannot pass with public information, with call-backs and manager approval for sensitive accounts. See the Account Recovery and Help Desk Security Guide.
- Standing privilege reduction: fewer permanent administrators, separate admin accounts and time-limited elevation.
- Identity detection and response: alerting on administrator changes, new MFA registrations, risky sign-ins and unusual service account behaviour, with someone empowered to revoke sessions at 3am.
- Machine identity governance: inventory, ownership and rotation for service accounts, keys and third-party app grants, starting with those that touch sensitive data.
Metrics to track
- Percentage of administrators, remote access paths and all staff on phishing-resistant MFA, reported separately.
- Number of standing privileged accounts in the identity provider, cloud and backup platforms, and the trend.
- Percentage of service accounts and API keys with a named owner and a rotation date in the last 12 months.
- Mean time from a high-severity identity alert to revoked sessions and reset credentials.
- Number of help desk resets for privileged users that bypassed the verified process (target zero).
- Date and result of the last identity-focused exercise, including a help desk impersonation test.
A 90-day plan
- Days 1 to 30: confirm the executive owner; ask management for MFA coverage by method and population; obtain a count of standing administrators in identity, cloud and backup systems; review the help desk reset procedure for privileged and executive accounts.
- Days 31 to 60: require phishing-resistant MFA for all administrators and remote access, with dated exceptions; tighten the reset procedure and test it with an authorised impersonation exercise; start an inventory of service accounts and third-party application grants with owners.
- Days 61 to 90: run an executive exercise based on an account takeover scenario, including a compromised identity provider administrator; confirm detection and containment times; baseline maturity with the Identity Security Maturity Model and set a 12-month target reported to the board.
Common failure patterns
- MFA with gaps: strong authentication on the main portal but a forgotten remote access gateway or test tenant without it, which is how the Change Healthcare intrusion started.
- The help desk as a back door: investment in authentication undone by a reset granted over the phone on the strength of publicly available facts.
- Treating SaaS identity as the provider's problem: customer accounts on cloud platforms left without MFA, network restrictions or rotation.
- Machine identities out of scope: service accounts and API keys excluded from MFA programmes and reviews, with no compensating controls.
- Detection with no responder: identity alerts generated but nobody authorised or available to revoke sessions quickly.
Practitioner checklist
- Report MFA coverage to the board by method (phishing-resistant or not) and by population: administrators, remote access, all staff.
- Require phishing-resistant MFA for every administrator and remote access path, with dated exceptions approved at executive level.
- Document and test a help desk verification process that impersonators cannot pass with public information.
- Keep a current count of standing privileged accounts and a plan to reduce it.
- Maintain an inventory of service accounts, API keys and third-party application grants with owners and rotation dates.
- Monitor identity provider and cloud administrator changes, MFA registrations and risky sign-ins around the clock.
- Rehearse recovery of the identity provider and directory as part of resilience testing.
- Run an account takeover exercise with executives every year and report closed actions.
Standards and references
- CISA: Implementing Phishing-Resistant MFA
- CISA and FBI: Scattered Spider Advisory AA23-320A
- US OMB: M-22-09 Moving the US Government Toward Zero Trust Cybersecurity Principles
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- UK NCSC: Cyber Security Toolkit for Boards
- NIST: Cybersecurity Framework 2.0
- Verizon: Data Breach Investigations Report
How NHI Mgmt Group can help
We provide independent identity and non-human identity risk assessments, board briefings and programme initiation support, covering human and machine identities alike. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Top 10 Identity Attacks · ITDR Guide · MFA Fatigue and Bypass Guide · Board Cyber Risk Reporting Guide