Identity-centric cybersecurity

Where we come from and why this article is the bridge

In the two previous articles we built the base: we defined what a digital identity is and we saw the four modern types (people, devices, workloads, AI agents), closing with the claim that identity is today the “new perimeter.” That claim is bold; in this article we’re going to back it up with three complementary lenses:

1. An organizational framework — NIST Cybersecurity Framework — that shows how IAM fits into the broader cybersecurity discipline.
2. An adversary catalog — MITRE ATT&CK — that teaches us to think like an attacker and understand why credentials are their number-one target.
3. Two industry reports — Verizon DBIR and Mandiant M-Trends — that contribute hard data: what happens in reality, not in theory.

NIST Cybersecurity Framework: the common language of cybersecurity

The NIST Cybersecurity Framework (CSF) is probably the most adopted framework for talking about cybersecurity in organizational terms. It was born in 2014 at the request of the US government for critical infrastructure, but quickly became the common language of companies, auditors, and regulators in much of the world. If a CISO asks you “how do you cover Detect?”, they’re speaking NIST CSF.

The reason CSF became so popular is practical: it doesn’t tell you what tool to buy or what process to adopt. It gives you a map of the functions that any security program should cover, and lets you choose how to cover them according to your context.

The six CSF functions, at a glance

Until 2023, CSF had five functions: Identify, Protect, Detect, Respond, Recover. In February 2024, NIST published version 2.0 and added a sixth, transversal function — Govern — that wraps around the other five. The reason: many organizations had technical capabilities but lacked the governance to make them sustainable.

The image below shows Govern as the hat covering everything (policies, roles, risk, supply chain), while the other five flow as a logical cycle. The dotted return arrow from Recover to Identify is important: every incident feeds your next cycle. If you don’t learn from what happened, you’re going to live the same incident again.

Fullscreen

The functions, one by one, with their IAM version

So they don’t stay as abstractions, here is each function with an example from the identity domain:

Function	What it seeks	Concrete IAM example
Govern	Establish and communicate policies, roles, and risk oversight	Corporate policy of “MFA mandatory for all production access,” approved by the executive committee
Identify	Know assets, risks, and dependencies	Inventory of identities — human and non-human — and mapping of what they can access
Protect	Implement safeguards	MFA, SSO, password vault, least privilege, segregation of duties
Detect	Discover anomalous activity	Alerts for impossible-geo logins, MFA bombing, unexpected escalation
Respond	Contain and mitigate the incident	Revoke sessions, disable compromised accounts, isolate the identity
Recover	Restore services and learn	Re-issuance of credentials, restoration of clean access, post-mortem and improvements

Where IAM fits inside the CSF

Here comes the claim worth memorizing: IAM mainly covers the first three functions (Identify, Protect, Detect), and ITDR — Identity Threat Detection and Response — closes the last two (Respond, Recover) when the threat is identity-related.

The schematic below pictures that division. On the left, the “classical IAM” cluster (IGA, Access Management, PAM) feeds Identify, Protect, and part of Detect. On the right, the ITDR cluster closes the loop by feeding Detect, Respond, and Recover. In reality, an IGA tool can also contribute to Detect via analytics and an IdP can contribute to Respond by revoking sessions, but as a mental map this division is the one most used in the industry.

Fullscreen

Identify with IAM

Identify answers the question “what do I have and what could happen to it?” In IAM terms, that means:

• Inventory of identities — human and non-human — their attributes, owners, and lifecycle.
• Inventory of applications and which identities access what.
• Mapping of privileged accounts and where they live.
• Risk scoring per identity: who has the most exposure.

If your organization can’t answer “how many ex-employees still have access to some app?” in less than 24 hours, you’re missing Identify coverage.

Protect with IAM

Protect answers the question “what do I put in the way so that damage doesn’t happen?” In IAM terms:

• Strong authentication: universal MFA, passkeys, gradual elimination of passwords.
• Granular authorization: least privilege principle, separation of duties (SoD).
• Automated provisioning: identities receive correct accesses at onboarding, lose them at offboarding.
• PAM: privileged accounts in a vault, recorded sessions, just-in-time access.
• User education: phishing simulation, training.

This is the function where most IAM programs invest the most. It’s where the tangible deliverables are seen (“we deployed MFA across 50 apps”).

Detect with IAM

Detect answers the question “how do I find out fast when something’s off?” In IAM terms:

• Logs of every authentication, every authorization, every config change.
• Alerts for anomalous patterns: impossible login (Madrid at 14:00, Tokyo at 14:05), MFA bombing (10 push notifications in 60 seconds), unusual account creation, privilege escalation outside hours.
• Integration with SIEM/SOAR to correlate identity with network, endpoint, and data.

This is where “classical” IAM (IdP + IGA) doesn’t suffice on its own anymore. The logs are there — but someone has to look at them. That brings us to ITDR.

ITDR closes the loop: Respond and Recover

Identity Threat Detection and Response (ITDR) is a category that Gartner formalized around 2022. The idea: identity infrastructure (Active Directory, Entra ID, Okta, etc.) is now a priority target, and needs its own detection and response plane — analogous to EDR (Endpoint Detection and Response) but for identities.

What does ITDR concretely do?

• Exposure discovery: active golden tickets, Kerberoasting paths, shadow admins, accounts with inflated permissions.
• Anomalous behavior detection: applies analytics (UEBA) over the identity plane to detect what static rules don’t catch.
• Orchestrated response: in the face of an alert, it can revoke sessions, disable accounts, force re-authentication, alert the SOC, all automatically.
• Forensic investigation: when the incident is over, it allows reconstructing what identity did what and when.

ITDR platform examples (mentioned as reference, not as recommendation): Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, Silverfort, Semperis, Quest. They all share the pattern: instrument the identity infrastructure and detect anomalies that the IdP alone doesn’t catalog as suspicious.

An analogy to keep them straight

A mental image that helps separate IAM from ITDR: think of IAM as the team of guards who let people in and out of the building — they verify credentials, log entry times, hand out the keys to each floor. And think of ITDR as the cameras and motion sensors that detect something off — someone hanging around an area where they shouldn’t be at 3 AM, someone trying to open 20 doors in a row, a key being used on two floors at the same time.

The guards (IAM) are indispensable, but on their own they can’t be everywhere at the same time. The cameras and sensors (ITDR) are what scale your ability to see. And a good security team needs both — they’re not alternatives.

MITRE ATT&CK: thinking like an attacker

If NIST CSF is the defender’s language, MITRE ATT&CK is the attacker’s language. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a giant catalog maintained by MITRE Corporation since 2013, where tactics (the goals an attacker pursues) and techniques (the specific methods they use to achieve them) are documented.

To understand why it matters for IAM: ATT&CK lets you look at your security program from the other side of the table. Instead of asking “do I have MFA?”, you ask “how would a real attacker bypass my MFA, based on documented cases?”. It changes your thinking from static defense to scenario-based defense.

The attacker’s journey, in plain language

ATT&CK organizes adversary behavior into 14 tactics. For an identity lens, the journey usually looks like this — get in, look around, escalate, steal more keys, move around, stay hidden, take or break things. The schematic below sketches that journey without the jargon. In real incidents the order isn’t this clean, but the stages are useful as a map.

Fullscreen

The techniques worth knowing

Each technique below has an identifier (T-number) that’s standard in the industry — you’ll see these codes in threat intelligence reports all the time. You don’t need to memorize them; treat the table as a glossary you’ll come back to.

ID	Technique	What it does	IAM defense
T1078	Valid Accounts	Use stolen legitimate credentials	Universal MFA, impossible-geo detection
T1110	Brute Force	Try passwords until hitting one	Progressive lockout, captcha, password spraying detection
T1566	Phishing	Trick the user into handing over credentials	Passkeys (phishing-resistant), education
T1003	OS Credential Dumping	Extract credentials from compromised OS (LSASS, SAM, ntds.dit)	EDR, Credential Guard, no use of local admin
T1558	Steal/Forge Kerberos Tickets	Golden ticket, silver ticket, Kerberoasting	KRBTGT rotation, ITDR, ticket monitoring
T1098	Account Manipulation	Modify accounts to maintain access (add admin, change password)	Alerts for sensitive changes, frequent certification
T1556	Modify Authentication Process	Manipulate the auth flow (Skeleton Key, MFA bypass)	Specialized ITDR, alerts on IdP changes
T1550	Use Alternate Authentication Material	Pass-the-hash, pass-the-ticket, OAuth token theft	Short tokens, mTLS, device binding

Why attackers prefer credentials

There’s a popular phrase in the industry: “attackers don’t hack anymore, they log in.” The reasoning is direct:

• A technical vulnerability (a buffer overflow, an SQL injection) requires finding the bug, writing the exploit, hoping the victim hasn’t patched.
• A valid credential opens the door without raising alarms. To the system, someone with the correct credential is legitimate by definition.

That’s why the cybercrime economy pivoted toward credentials. There’s a mature black market where valid credentials for specific companies are sold (the “initial access brokers”), priced from 10 to several thousand dollars depending on value. Ransomware groups increasingly don’t look for vulnerabilities — they buy ready-made access.

A story to fix the concepts: an attack on a fictional fintech

So the techniques don’t stay in a table, let’s walk through a realistic scenario. Let’s say we’re a medium fintech in Central America with 400 employees and 200,000 active customers. We have Microsoft Entra ID as IdP, MFA via mobile app for employees, and a SOC shared with a regional MSSP.

On a Monday at 7:43 AM, an attacker sends a credible phishing email to 30 employees, impersonating the HR team with a PDF supposedly about “benefits update.” Three employees click. One of them — David, from the finance team — enters his credentials in a fake site that mimics the Entra ID screen. This is T1566 Phishing.

By 7:51 AM, the attacker already has David’ credential. They start a session from an IP in another country. The IdP demands MFA. The attacker fires consecutive push notifications to David’ phone. After the fifth notification in a row, David — half asleep and assuming it’s a system glitch — approves. This is MFA bombing, a variant of T1078 Valid Accounts combined with psychological pressure.

By 7:55 AM, the attacker is inside as David. David is a finance analyst, not an admin. But the attacker doesn’t need to be an admin yet: they start reading emails looking for sensitive information. They find a thread where credentials of a treasury system are being discussed. This is discovery and internal reconnaissance.

By 9:12 AM, using information from the emails, the attacker tries access to the treasury system with a weak service credential (a treasury_app user with a password that hadn’t rotated in 4 years). They get in. This is T1078 (Valid Accounts) plus a poorly managed non-human account.

If the fintech had ITDR instrumented over its Entra ID, alerts would have fired at least at four points: impossible-geo login, MFA bombing, atypical David behavior (massively accessing emails in one hour), and use of a service account outside its typical pattern. Without ITDR, all of that stayed in logs nobody looked at until Tuesday afternoon.

This is the daily reality of the modern SOC. The difference between “we detected it in 5 minutes” and “we detected it once they had already extracted data” is whether you have the right lenses on.

The reports that drive the conversation: DBIR and M-Trends

So conversations about IAM don’t stay in opinions, it’s worth anchoring them in data. There are two annual reports anyone in this domain should read at least the executive summary of: the Verizon DBIR and the Mandiant M-Trends.

Verizon DBIR (Data Breach Investigations Report)

The Verizon DBIR comes out every April since 2008. It’s the broadest investigation that exists on data breaches: in the 2024 edition they analyzed more than 30,000 incidents and almost 11,000 confirmed breaches, contributed by 94 organizations from around the world (including national CSIRTs and detection providers).

Key findings of recent editions, summarized:

• The human element is in 68% of breaches. Not always malicious — it can be misconfiguration, falling for phishing, or improper use through carelessness.
• Compromised credentials are the most common initial vector for breaches in web systems. The typical chain: phishing → stolen credential → access to SaaS → exfiltration.
• Ransomware maintains a constant presence, but increasingly combined with extortion based on exfiltration (not only encrypting, also threatening to publish).
• The mean time to detection is still measured in weeks, not minutes, which gives the attacker room to maneuver.

Mandiant M-Trends

The Mandiant M-Trends is complementary to the DBIR. While the DBIR is a broad, statistical view, M-Trends comes from the forensic angle: Mandiant (part of Google Cloud since 2022) does incident investigation in large companies, and each year publishes a report with trends observed in their cases.

Typical findings relevant to identity:

• Dwell time: how many days the attacker was inside before being detected. In their best years the average came down to around 10 days; in recent years it has gone back up, especially when the initial vector was a valid credential (because it goes more unnoticed).
• Abuse of valid accounts as dominant tactic: in most of the cases investigated, the attacker used T1078 (Valid Accounts) at some point.
• Attacks on identity infrastructure: attacks aimed at the IdP, federated directories, and SSO flows. Cases like SolarWinds (Golden SAML) or the Okta breach fall here.
• MFA bypass: growing techniques to circumvent MFA — push fatigue, adversary-in-the-middle (AitM) attacks with kits like Evilginx, session token theft.

Why both reports matter together

The two reports complement each other:

• DBIR: breadth. It gives you the picture of the whole ecosystem.
• M-Trends: depth. It gives you the detail of what happens in real investigations.

A good mental exercise: when you read a news headline about a big breach, look it up afterward in M-Trends of the following year and you’ll see the systematized pattern. And when a CISO tells you “we need to justify the investment in MFA,” opening the DBIR and showing the data that “68% of breaches have a human element” usually persuades better than any slide.

A real case: Lapsus$ and why frameworks matter

To land everything above, let’s see how the three lenses (CSF + ATT&CK + reports) connect in a real case.

In January 2022, the Lapsus$ ransomware group compromised an outsourced technical support provider of Okta. From a support engineer’s account, the attackers accessed the internal admin console, which potentially gave them visibility over customer tenants. The final scope was limited by quick response, but the incident shook the industry — because it showed that identity infrastructure itself can be the target.

Lens 1: Mapping to MITRE ATT&CK

The attackers walked through five steps you’ll recognize from the journey above: phishing the engineer (T1566), stealing his credential (T1078), reaching the internal console with that credential (T1078.004 — Valid Accounts in cloud), modifying the auth flow to reset a victim’s MFA (T1556), and finally manipulating accounts to extend access to customer tenants (T1098). If your organization had explicit alerts for T1078.004 and T1556, you’d have had the chance to detect faster.

Lens 2: Mapping to NIST CSF

Function	Specific failure observed	Mitigation that would have helped
Identify	Risk of outsourcing administrative access wasn’t mapped	Threat model that includes vendors
Protect	Administrative access without phishing-resistant MFA	Mandatory passkeys or hardware keys for admins
Detect	Delay in detecting abuse of the support account	ITDR over the Okta console
Respond	Communication to the customer was perceived as late	Pre-rehearsed communication playbook
Recover	Review of potentially affected tenants	Public post-mortem and structural improvements

Lens 3: What we saw in DBIR/M-Trends

The pattern “attacker enters via vendor + abuses valid account + extends access” appears in M-Trends 2022 and 2023 as one of the most frequent in high-impact incidents. The DBIR 2023 dedicated a section to “supply chain interconnection” precisely because of cases like this.

The structural lesson: your identity security doesn’t end at your employees. It ends where the chain of organizations with administrative access to your infrastructure ends.

Recap

We’ve covered the three lenses worth having when talking about identity-centric cybersecurity:

• NIST CSF gives you the organizational language. IAM mainly covers Identify, Protect, and Detect; ITDR closes Respond and Recover when the threat is identity-related.
• MITRE ATT&CK gives you the adversary’s language. Techniques T1078, T1110, T1098, and T1556 are the ones most worth knowing because they appear in nearly every modern identity-related incident.
• DBIR and M-Trends give you the data. The human element is in 68% of breaches and credentials are the most exploited vector — not because the technology is weak, but because the cybercrime economy reoriented toward them.

If you carry these three lenses with you to any security conversation — with your CISO, with an auditor, with a customer — you’re going to be able to translate the technical (an MFA roll-out, an IGA project) to organizational impact. And that, more than any certification, is what distinguishes a good IAM professional.

Three questions to test yourself

1. You’re assigned to redesign the security program of a regional fintech. How would you describe the role of IAM within the six functions of the NIST CSF, in less than a minute, to a non-technical executive committee?
2. If you could only deploy defenses for three MITRE ATT&CK techniques in the next 90 days, which would you choose and why? Justify with DBIR data if you can.
3. Your IdP starts seeing “MFA bombing” patterns against several privileged users. What CSF function is failing, what ATT&CK technique are the attackers using, and what ITDR capability would be most useful to respond?