Identity and access management (IAM)
We put your organization’s access in order: who can access what, with what authentication, and what happens when someone joins, changes roles, or leaves.
When you need it
Signs that access rights are in disarray
Most organizations run into these situations, and each one leaves an opening for attackers.
No overview of permissions
When permissions have been granted one at a time for years, it is hard to say who can access the finance system, for example, and why.
Shared accounts
An account used by several people cannot be traced: after an incident, nobody can tell who did what.
Passwords without a second factor
Attackers most often get in with stolen credentials. Multi-factor authentication stops the vast majority of these attempts, but only where there are no exceptions, such as a legacy mail protocol or the internal network.
Reused passwords
Without a password manager, users reuse the same password in several places, so a single outside leak is enough to get in.
The access lifecycle
Joining, changing roles, leaving
These are the moments when permissions change. Each one needs a written process with named owners and deadlines.
Joining
A new employee gets the access that belongs to their role, so from day one it is clear what they can access.
Changing roles
People who move to another department often keep their old access too, and their permissions pile up over time. When they move, the new role’s permissions replace the old ones.
Leaving
Access is revoked on the day notice is given, service account passwords are changed if the departing employee knew them, and devices are collected. In practice, this is the step that gets skipped most often.
Deliverables
What you get at the end
items handed over
- Assessment of current permissions
- Role-based access model
- Multi-factor authentication on critical systems
- Documented onboarding and offboarding processes, automated where possible
Related services
Other parts of identity protection
Access management is the foundation. Each of these services takes one area further.
Privileged access management (PAM)
Administrator rights become temporary, approval-based, and logged.
Active Directory review and hardening
An audit of permissions, accounts, and settings, then closing off the attack paths.
Zero trust remote access (ZTNA)
Replacing the traditional VPN with application-level access: users only see what they are authorized for.
Microsoft 365 security hardening
Checking and fixing the authentication and Conditional Access settings of your cloud tenant.
Frequently asked questions
The questions we hear most
Which multi-factor authentication method should we choose?
Code-based methods (SMS, email, authenticator app) do not protect against phishing, because a fake sign-in page relays the code in real time as well. Push notifications with number matching largely resist this. FIDO2 hardware keys and passkeys are the strongest, because the authentication is cryptographically bound to the domain. We compared the methods in our article MFA types: what each one is actually worth.
Where should we start rolling out multi-factor authentication?
With the services reachable from outside: VPN, remote desktop, webmail, and cloud applications. Administrator accounts come next, preferably with a hardware key, followed by high-risk roles such as finance, HR, and management. Finally, every user.
What should we do with service accounts that cannot use MFA?
Rather than being made exceptions, they get other safeguards: a long, unique password, narrow permissions, and a restricted sign-in location, meaning they can only sign in from the server they need to run on. Where possible, they are replaced by managed accounts whose passwords the system handles and rotates. They should never have domain administrator rights. We covered them in more detail in our article Password management in the enterprise.
Who should decide who gets access to what?
Department managers have to be involved in the access review, because they are the ones who can say what each person needs for their work. IT provides the technical side: the roles and the assigned permissions. We also wrote about this in our article Zero Trust architecture: a practical guide.
