Do we need an identity management system?

For most mid-sized companies, not right away. Personal accounts, MFA, a password manager and fixed processes solve most of the problem — an IAM system can follow later.

How does this work without blocking daily business?

Step by step: critical systems first, clear transition periods, and rights granted along actual tasks. Done well, everyday work barely notices.

What does this have to do with NIS2?

Access control and traceability are among the core requirements. Whoever has order here has already completed a large part of the mandatory programme.

Is a password manager not enough?

It is an important building block, but it does not replace a role model or an offboarding process. Only the combination keeps things in order permanently.

Do you also handle the technical implementation?

Yes — from structure to implementation with your IT team or service provider, including modern approaches like SSO, OAuth2 or policy-based authorization (e.g. OPA).

Bring access and permissions in order — before someone else does

"IT@company123" — one password, for years, for everyone. What began as a pragmatic solution eventually becomes the company's biggest open door.

Permissions grow historically: whoever once got access keeps it. Whoever leaves often stays registered. Whoever covers for a colleague quickly gets admin rights. And nobody can say who is actually allowed to do what.

The topic feels uncomfortably big — but with clear priorities it is very manageable: first an overview, then the critical accounts, then a process that keeps things in order.

When access becomes a risk

Typical signs that permissions are getting out of hand:

Shared accounts and shared passwords are everyday practice
Former employees or externals still have active access
Nobody can list who can access which systems and data
Admin rights are handed out generously — "to keep things moving"
Passwords live in Excel lists, notes or emails
In case of an incident, it would be impossible to trace who did what and when

Each of these points is uncomfortable on its own. Together they are exactly what attackers look for — and auditors find.

Typical access shadow processes

Shared accounts

One login for the whole team — nobody knows who did what, and the password is also known to whoever left last year.

Rights accumulation

With every role change, permissions are added — rarely is anything revoked.

Admin for everyone

Full rights out of convenience: every mistake and every hijacked account has maximum impact.

Externals with permanent access

Service provider accounts that simply keep running after the project ends.

No traceability

Without personal accounts and logs, every incident remains a mystery.

Why access chaos persists so long

It rarely comes from carelessness — but because:

It works in everyday business, at first
Revoking rights is more inconvenient than granting them
Nobody is explicitly responsible for permissions
On- and offboarding run without fixed checklists
The topic feels like a "big IT project" and therefore stays untouched

The right time to act is much earlier than most think — at the latest when customers, insurers or NIS2 ask for evidence.

Signs that it is time to act

It is worth taking a closer look when several of these points apply:

There are shared accounts for business-critical systems
Offboarding does not reliably remove access
Externals have permanent access to internal systems
More people have admin rights than there are admins
Passwords are stored unencrypted or shared
A cyber insurer or a customer asks about your permission concept
NIS2 or other requirements are approaching
An incident or near-incident has raised questions

What makes a good solution

Cleaning up permissions does not mean touching everything at once. What matters first:

1 Which systems and data are truly critical?
2 Who needs which access for their daily work?
3 Where is read access enough, where are write or admin rights needed?
4 How does access get in — and how reliably does it get out again?
5 What needs to be traceable if something happens?

Sensible building blocks include:

Personal accounts instead of shared logins
Role-based permissions: rights follow the task, not the history
A team password manager instead of Excel lists
Multi-factor authentication for critical access
Fixed on- and offboarding processes with checklists
Regular permission reviews — short but consistent

Modern systems support this well — from central login (SSO) and OAuth2 to policy-based authorization. The order matters: critical accounts first, refinements later.

How I approach cleaning up access

Create an overview

We map systems, access and accounts — including the forgotten ones: legacy accounts, externals, shared logins.

Assess criticality

Not everything is equally important. We prioritise by the damage a misused account could cause.

Implement quick wins

Close orphaned accounts, change critical passwords, enable MFA — the fast, big levers first.

Build structure

Role model, password manager, on-/offboarding process — so order is maintained without a permanent project.

Keep it up

A light rhythm of permission reviews ensures the chaos does not accumulate again.

Typical results from such projects

Clarity about who can access what
A significantly smaller attack surface
Traceability when it matters
Solid answers for insurers, customers and audits
On- and offboarding without loose ends
Less risk from legacy access and former employees

Practical context: typical starting points

In practice this is rarely a technology problem: the systems could usually do more than is being used. What is missing is the overview — and a process that keeps order when people join, leave and change roles.

That is why the work does not start with a new tool, but with an honest inventory. The technology — from password manager to policy-based authorization — follows after.

Which support can make sense

Access and permissions touch several areas — from security analysis to technical structure:

IT Security – when access, risks and requirements like NIS2 need clarity
Software Architecture & Technical Project Leadership – when systems and technical decisions need structure
Connecting systems – when ERP, CRM and business applications do not talk to each other
All services at a glance

Häufige Fragen

Do we need an identity management system?: For most mid-sized companies, not right away. Personal accounts, MFA, a password manager and fixed processes solve most of the problem — an IAM system can follow later.
How does this work without blocking daily business?: Step by step: critical systems first, clear transition periods, and rights granted along actual tasks. Done well, everyday work barely notices.
What does this have to do with NIS2?: Access control and traceability are among the core requirements. Whoever has order here has already completed a large part of the mandatory programme.
Is a password manager not enough?: It is an important building block, but it does not replace a role model or an offboarding process. Only the combination keeps things in order permanently.
Do you also handle the technical implementation?: Yes — from structure to implementation with your IT team or service provider, including modern approaches like SSO, OAuth2 or policy-based authorization (e.g. OPA).

Do you know who can currently access your systems?

A compact assessment creates clarity — and shows the measures with the biggest leverage.

Let's talk about it