Wat een interne identity-assessment meestal blootlegt

Dit artikel is momenteel in het Engels beschikbaar. Als je het liever samen in het Nederlands bespreekt, nemen we dat graag mee in een gesprek.

When people ask what an internal identity assessment usually finds, they often expect something dramatic. A hidden backdoor. A clever exploit. A strange configuration nobody could reasonably have predicted. Sometimes there is a surprise, but most of the serious paths are quieter than that. They come from trust that kept expanding after the original reason for it disappeared.

Identity environments age in layers. A privilege model that made sense before a merger, a cloud migration, an outsourcing change, or a rushed application rollout can become dangerous without any one person making an obviously reckless decision. By the time an attacker lands on a workstation, the path forward is often less about brilliance and more about using the permissions the organisation has slowly made available.

The finding is usually a path, not a single setting

Identity risk rarely announces itself as one bad checkbox. It appears as a chain. A user has more access than expected. A group is nested into another group that nobody reviews. A service account can read or modify something sensitive. A workstation administrator path leads into server administration. A cloud role grants a path back into identity. Each step looks explainable on its own. Together, they become movement.

This is why the output of an identity assessment should not be a pile of graph screenshots. The graph matters, but the client needs the story behind it: where the attacker starts, what they can touch next, which trust relationship makes the jump possible, and where the path becomes business-relevant.

Common places where paths appear

Privileged groups are the obvious place to start, but they are not the only one. Old administrative memberships, delegated OU rights, stale helpdesk privileges, unmanaged local administrator access, certificate-service abuse paths, risky service accounts, excessive share permissions, weak workstation boundaries, and cloud identity roles can all matter. The important part is not naming every possible technique. The important part is understanding which combinations are reachable in your environment.

Hybrid identity adds another layer. Active Directory, Entra ID, M365, device management, single sign-on, VPN, privileged-access tooling, and SaaS administration often overlap in ways that ownership charts do not show. A team may believe it owns only a small slice of access while the effective path crosses infrastructure, endpoint, cloud, and application administration.

Service accounts are rarely boring

Service accounts are easy to ignore because they support real systems. They are also easy to over-permission because nobody wants to break the integration. Over time, the account becomes important, poorly understood, and difficult to rotate. It may have broad read access, database access, local administrator rights, delegation rights, or secrets stored where more people can reach them than intended.

The question is not simply whether a service account is "secure". The useful question is what happens if it is recovered, replayed, delegated, or used from the wrong place. Can it move laterally? Can it reach sensitive data? Can it change identity objects? Would anyone notice the difference between normal service activity and abuse?

Workstation boundaries often decide the outcome

Many internal compromises become serious because workstation compromise is treated as less important than server compromise. That is understandable until a workstation also has cached admin material, broad local admin reuse, remote management privileges, access to management consoles, or a direct path into identity administration. The attacker does not need every machine. They need the right one.

A good assessment looks at where administration actually happens. Are privileged actions performed from hardened workstations? Are admin roles separated from daily accounts? Can support tooling become a bridge into higher privilege? Are remote management paths monitored as sensitive activity or treated as background noise?

Cloud identity can change the blast radius

Many organisations think of cloud identity as separate from internal identity because different teams manage it. Attackers do not care about that boundary. If an internal foothold can reach tokens, sync paths, privileged cloud roles, automation accounts, or application credentials, the impact can move quickly from "one endpoint" to "several business services".

The same works in reverse. A cloud-side weakness may create a path back into internal administration or sensitive data. That does not mean every assessment needs to become a full cloud review. It does mean internal identity work should not stop at the old domain boundary if the real business environment has moved past it.

Why these issues stay hidden

Identity weaknesses persist because every exception has a local reason. The helpdesk needs to support users. The project team needed temporary access. The integration was urgent. The admin model was inherited. The old group was never removed because nobody was fully sure what would break. None of those explanations are absurd. The problem is that attackers benefit from the combined effect, not the individual justification.

This is why an internal identity assessment is often valuable before a red-team exercise. It removes avoidable noise. If domain-impacting paths exist through basic design debt, a broad simulation may spend expensive time proving what a focused identity assessment could have shown more directly.

What useful output looks like

A useful report separates the path from the clean-up. Some issues are immediate attack enablers. Some are hygiene. Some belong to architecture. Some belong to operating process. Treating all of them as equal creates a remediation backlog that nobody trusts. The debrief should make the first few decisions obvious: which path must be broken, who owns the change, what can be monitored while the fix is being planned, and what deserves longer-term redesign.

The best output also gives defenders something to work with. If the path used suspicious LDAP queries, unusual group changes, remote management, ticket requests, token use, or admin activity from the wrong place, those details should become detection and response improvements. Identity assessment should leave the organisation harder to move through, not just more aware of its diagrams.

When to run one

The right moment is usually when the organisation has a reason to doubt its assumptions. A merger. A cloud migration. A privileged-access project. A ransomware-readiness push. A new SOC. A customer assurance request. A red-team exercise on the horizon. Or simply the feeling that nobody can explain, with confidence, what a compromised workstation could become.

That last question is often the most useful starting point. If an attacker gets a normal user account and one endpoint, what stops the path there?

---

If you suspect identity has become more trusted than it has become controlled, let's scope it properly. Internal identity work is often the fastest way to separate background worry from a real attack path.