Identity-based attacks are the type of attack that doesn’t set off any alarm bells. The NCSC sums up the problem in a single sentence: it’s becoming increasingly common for hackers not to break in, but rather to log in using legitimate credentials. In such cases, there is no exploit, no malware, and no unusual network traffic. There is a successful login—just like thousands of others that day. Yet most Dutch organizations still treat identity management as an administrative task and detection as a security task, even though this type of attack thrives precisely at the intersection of the two.
What the Numbers Do and Don't Tell Us
Verizon’s 2026 Data Breach Investigations Report reveals a shift that is often misinterpreted. Globally, credential stuffing has dropped to 13 percent of breaches, meaning that exploiting vulnerabilities has taken the lead as the primary method of entry. In the EMEA region, however, that figure stands at 25 percent—nearly double the global average.
For anyone who takes identity-based attacks seriously, that regional difference is the relevant finding. Identity-based attacks are a proportionally bigger problem here than global headlines suggest, and the decline in the global figure does not mean that there are fewer attacks, but rather that other attack vectors are growing more rapidly.
The report also reveals a painful vulnerability among supply chain partners: of the third parties examined, only 23 percent had fully resolved issues with missing or incorrectly configured multi-factor authentication on cloud services. In cases involving weak passwords and incorrectly configured permissions, it took nearly eight months for half of the findings to be resolved. These are not detection issues but management issues, and they do determine whether your detection team will have anything to do.
Why Your SOC Can't Solve This on Its Own
In the case of identity-based attacks, a SOC analyst reviewing a successful login asks three questions: Is this the right person? Is this person authorized to access this system? And is this behavior normal for this person? The answers to none of these three questions can be found in the security platform. They are found in the identity infrastructure: in the authorization matrix, in the role structure, and in the history of who was granted which permissions and when.
Without that context, an alert about an unusual login cannot be assessed. A login from Germany at 6:30 a.m. is either suspicious or completely normal, depending on whether this employee works in a border region. In the case of identity-based attacks, the quality of your identity management therefore directly determines how effective your detection is. This is the same dependency we described regarding SIEM investments without trained analysts: the platform only delivers a return on investment if the surrounding infrastructure is in order.
The NCSC explicitly identifies the shortcomings that cause this: insufficient control over user rights leads to overly broad access, structural privilege accumulation, and unmanaged accounts. Privilege accumulation is the most underestimated of these: an employee who held four positions over the course of twelve years and was granted new permissions with each change without having the old ones revoked is a more attractive target than the system administrator themselves. Identifying such structural shortcomings aligns with the approach outlined in our article on the cybersecurity maturity model.
The Skills Profile of an IAM Engineer
This is the crux of the problem that makes identity-based attacks so effective in Dutch organizations. IAM is almost always managed by the systems administration team, and the skills required there are not the same as those needed to prevent identity-based attacks. A good administrator ensures that people can work. An IAM engineer ensures that people can do exactly what they need to do—and nothing more—which is a fundamentally different approach.
Specifically, identity-based attacks require four competencies that are rarely found in an administrator’s job description: designing a role structure that aligns with the organization’s current needs rather than its history, including periodic reassessment of permissions; Assessing authentication methods for their resilience against specific attack techniques. Setting up logging for identity events so that detection systems can make use of the data. And thinking from the perspective of abuse: what path would an attacker take starting from this account?
That last skill is an attacker’s mindset, and you can’t learn it from an administration manual. It’s the same way of thinking that’s central to the Penetration Testing course, where participants learn to reason like an attacker. An IAM engineer who has personally followed a path from a regular user account to a domain administrator designs permissions differently than someone who only knows this in theory.
Authentication is a risk-based decision, not a checkbox
Many organizations consider their resilience against identity-based attacks to be sufficient once multi-factor authentication is enabled. The NCSC is clear on this point: not all forms of authentication are equally secure. Authentication via text message or email using a one-time code is the least secure method because it leaves the door open to phishing and man-in-the-middle attacks, in which the attacker also intercepts the code for the second step.
The resulting recommendations for defending against identity-based attacks are more nuanced than a generic policy. Categorize accounts by impact, and secure them accordingly: administrator accounts require phishing-resistant authentication in accordance with the FIDO2 standard, while guest accounts do not. With FIDO2, the private key never leaves the registered device, and login credentials are unique to each system, rendering any intercepted credentials useless.
Making this trade-off requires someone who understands both the technology and the business process. If you make the security measures too strict, users will find workarounds and the measure’s effectiveness will decline—exactly as the NCSC warns regarding user-friendliness. If you make the security measures too lax for the accounts that matter, the measure will be merely cosmetic. Identity-based attacks will unfailingly target the accounts where that trade-off was mishandled.
How IAM and SOC Work Together in Practice
Collaborating to combat identity-based attacks does not mean that both teams will take over each other’s work. It means that three things must be in place before anything goes wrong. First, IAM provides the context that detection requires: an up-to-date overview of roles, accounts with elevated privileges, and exceptions to the standard policy. Without that overview, every identity alert requires an investigation from scratch.
Second, the security team determines which events that indicate identity-based attacks will automatically trigger an alert: a newly created administrator account, a change to forwarding rules, an OAuth authorization granted, or a login from an unknown device on a high-impact account. These aren’t unusual indicators, but they’re rarely monitored because no one feels responsible for them.
Third, there is an agreement on what happens after a confirmed compromise. Resetting a password is not enough when an attacker has already obtained a session token, an application permission, or a second factor. This requires a detailed procedure that both teams are familiar with, similar to the approach outlined in our article on threat hunting within the existing team. Anyone who wants to extend the identity chain to suppliers can find the approach in our article on supply chain security.
Train Instead of Recruit
The job market for engineers who can prevent identity-based attacks is tight, and the job title has not yet been clearly defined in the Netherlands, which means that job postings often list an impossible combination of requirements. Our article on writing cybersecurity job postings explains why this costs candidates, and our article on the hidden costs of a vacant position details the financial implications of delays. For most organizations, internal training is therefore the faster route.
The starting point for building resilience against identity-based attacks is a good one. The people you need are already in your organization: administrators who know the environment inside and out and are only missing the security layer. The Cyber Security Specialist training program is designed specifically for that transition and brings an IT employee up to a deployable security level in fifteen weeks, including the network and system fundamentals on which identity management is based. Those looking to strengthen their detection capabilities should consider the SOC T1 + T2 Analyst training program for triaging identity alerts, or the SOC T3 Analyst training program for independently investigating the scope of a compromise.
If a case comes down to presenting evidence—for example, because an account was found to have been compromised for months—the quality of the investigation matters; the Cyber Forensics Expert program focuses on evidence that will stand up to scrutiny later on. And because identity management is a logical stepping stone to broader engineering roles, this aligns with the career path we described, from SOC analyst to security engineer.
Think in terms of learning paths rather than individual courses. Identity-based attacks require people who are proficient in both design and detection, and you build that combination over several steps. We outlined which roles you need for this and in what order in our guide to building your first security team and in our article on career paths as a retention tool. That perspective is also what keeps people engaged: an administrator who sees a clear path to a specialized role is less likely to leave.
Certifications alone rarely cover this combination, as we argued earlier in “Certification vs. Experience.” What matters is whether someone can design a role structure that will still be valid three years from now, and that’s something you test in practice. It’s the same reasoning as in “Structural Improvements in Information Security”: structural capacity over isolated measures.
The page for employers explains how to build such a learning path based on your current setup—from open-class courses to in-company programs in your own identity management environment. You’ll find the complete overview of levels for all training programs. Would you like to discuss which path best suits the maturity level of your identity management? Check out the upcoming start dates or schedule an introductory meeting.
