Identity & Access Management (IAM)

What identity and access management (IAM) covers

Identity and access management (IAM) is the set of policies and tools that decide who an account belongs to and what that account is allowed to reach. In most organisations it spans an identity provider, a user directory, authentication, and the access rights tied to each role. The field is broad, and no single tool does all of it. Knowing which part you are solving for is the first step in any IAM project.

Where ServiceChanger fits in identity and access management

ServiceChanger does not authenticate users. It does not do single sign-on or multi-factor authentication. By default it reacts to the attributes already in your directory rather than reading an HR system out of the box. It sits after your identity provider. Once an account exists in Microsoft Entra ID or on-prem Active Directory, ServiceChanger turns one attribute value (department, job title or location) into the right set of group and role memberships, and keeps that set correct automatically. So if "department = Finance" should mean nine specific groups, ServiceChanger makes sure those nine memberships are always present and nothing extra. If you want to connect your HR system for onboarding and offboarding, we build that as custom work using automation accounts and runbooks in Azure. It is one access-automation layer, not a full IAM or IGA suite.

One attribute maps to a set of groups and roles

The core idea is simple. You map one attribute to a whole set of memberships. "Job title = Field Engineer" can map to a VPN group, a remote-access role, three shared mailboxes and the right software-deployment groups, all from a single value. When someone moves from Sales to Finance, the Sales memberships drop and the Finance set is added, because the mapping is evaluated continuously, not once at onboarding. Examples we see in practice: department = Finance to nine groups, location = Rotterdam to a printer group plus a site distribution list, and job title = Manager adding an approvals role on top of the base set for the department.

Entra ID and on-prem Active Directory in one model

Most organisations are still hybrid: some groups live in Microsoft Entra ID, others only exist in on-prem Active Directory. ServiceChanger writes to both from the same model. It can drive Entra ID dynamic groups, work alongside Entra Connect for the synced objects, and run a PowerShell runbook on a hybrid worker for the on-prem groups that no cloud-driven group can reach. That means a single "department = Finance" mapping can fill a cloud security group and an on-prem AD group at the same time, with no second tool and no manual export. This hybrid coverage from one model is the part most generic IAM tooling skips.

Continuous enforcement, not a one-time sync

Access drift is the slow problem in every directory: people keep memberships they no longer need, and manual cleanups never quite catch up. ServiceChanger re-applies the attribute model on a schedule, so a membership that should not be there gets removed and a missing one gets added back. There is no shadow mode and no preview-only run; the attribute model is the source of truth and it is enforced on every pass. This keeps the gap between "what the attribute says" and "what the directory grants" close to zero between access reviews.

Where authentication and lifecycle still belong

Because ServiceChanger handles memberships, the rest of IAM stays with the tools built for it. Single sign-on and multi-factor authentication remain in your identity provider; they verify who is signing in. By default ServiceChanger assumes the account already exists and the attributes are already set, then makes sure the access that should follow from those attributes is correct. If you want to connect your HR system so onboarding and offboarding drive those attributes, we build that as custom work using automation accounts and runbooks in Azure. The two layers fit together: identity providers decide if you may sign in, ServiceChanger decides which groups you land in.

What the license module does and does not do

The license module tracks usage. It shows which licenses are assigned and how they line up against your group and role model, so you can spot over-assignment before an access review does. It does not provision licenses and it does not reclaim them. Removing or buying back a license stays a deliberate action in your own admin tooling. The module gives you the visibility to decide; it does not make the change for you.

IAM, compliance and access reviews

Access reviews ask one question: does every membership still have a reason. When memberships follow from attributes, the reason is the attribute value itself, which makes reviews shorter and audit evidence cleaner. ServiceChanger does not replace your audit or reporting tools, but attribute-driven memberships give them a consistent, explainable answer for standards such as GDPR, HIPAA and SOC 2: this group exists because this attribute has this value.

Where IAM is heading

The wider IAM field keeps moving toward zero-trust models, where access is never assumed and is checked at the point of use, and toward passwordless sign-in with passkeys and FIDO2. Those shifts happen in the authentication layer. What stays constant underneath is the need for correct group and role membership, because a zero-trust decision is only as good as the access data it reads. Keeping that membership accurate and attribute-driven is the part ServiceChanger handles, whatever the sign-in method on top.

IAM components: the building blocks of an IAM system

An IAM system is not one product. It is a stack of components that each solve a different part of the problem, and most organisations assemble them from a few tools. Knowing the components helps you see where a gap is and which tool fills it.

• Identity provider:the service that holds the authoritative record of who a user is and issues the token that proves it at sign-in. In a Microsoft shop this is Microsoft Entra ID. It answers "is this really them".
• Directory:the store of user and group objects with their attributes: department, job title, location, manager. Microsoft Entra ID and on-prem Active Directory are the two directories most companies run, often side by side. This is the data ServiceChanger reads to decide memberships.
• Authentication:the check at sign-in, including single sign-on, multi-factor authentication and passwordless methods. It confirms the person in front of the screen matches the identity. This layer stays in your identity provider.
• Authorisation:the decision about what an authenticated account may reach, expressed as group and role memberships. This is the layer ServiceChanger automates from directory attributes.
• Provisioning:creating, updating and removing accounts and their access over a user lifecycle. Account creation and HR-driven joiner-mover-leaver flows sit here; ServiceChanger keeps memberships correct once an account exists, and HR-driven provisioning is custom work with automation accounts and runbooks in Azure.
• Governance:the oversight layer: access reviews, certifications, segregation-of-duty checks and audit evidence. Attribute-driven memberships give this layer a cleaner answer, but a full IGA suite owns the certification workflow itself.

IAM vs IGA vs PAM: which one solves which problem

Three terms get mixed up in almost every IAM project, and buying the wrong category wastes money and time. Here is what each one solves and when you actually need it.

Where ServiceChanger fits: the membership and authorisation layer of IAM, for Microsoft Entra ID and on-prem Active Directory. Not an IGA suite, not a PAM vault. If your problem is "the wrong people are in the wrong groups and it drifts", that is the ServiceChanger problem. If your problem is "we cannot prove our reviews" or "our admin accounts are unmanaged", that is IGA or PAM.

IAM implementation: a realistic step-by-step

An attribute-driven IAM implementation is not a big-bang project. It works best as a sequence, one department at a time, so a data problem in one place does not stall the whole rollout. Here is the order we run, with a realistic time indication per step for a mid-sized organisation.

1. Inventory the attributes (1 to 2 weeks):list which directory attributes you actually have populated (department, job title, location, manager) and how consistent the values are. This is the honest starting point, and it is usually messier than people expect.
2. Fix data quality (2 to 4 weeks):clean the attribute values so "Finance", "finance" and "FIN" become one value. The mapping is only as good as the data underneath, so this step pays back every later step.
3. Design the mapping (1 to 2 weeks):decide which attribute value should grant which set of groups and roles. Group mining helps here: it looks at existing memberships and suggests which groups already correlate with which attributes.
4. Pilot on one department (2 to 3 weeks):run the model on a single, well-understood department. Keep it small enough to check every result by hand and catch the mapping mistakes before they scale.
5. Roll out per department (4 to 8 weeks):expand department by department, not all at once. Each one has its own edge cases, and a staged rollout keeps the blast radius small.
6. Handle exceptions (ongoing, front-loaded):some people genuinely need access their attribute does not grant. Record every exception with an owner and a reason so it stays visible and does not become silent drift.
7. Move to steady-state management (ongoing):once the model is applied continuously, the day-to-day work shifts from granting access to maintaining the mapping and the attribute data. Add the self-service portal here so people request access and a manager or owner approves.

IAM on Microsoft Entra ID and on-prem AD in practice

Most of the questions we get are Microsoft-specific, because that is where the group model gets awkward. A few things worth knowing before you assume dynamic groups will cover it.

• Dynamic groups and their limits:Entra ID dynamic groups already assign membership from an attribute rule, and for simple cases they are great. They fall short when a single attribute has to drive many groups at once, when you also need on-prem AD groups, or when the rule needs logic a membership expression cannot express. That is the gap an attribute model fills.
• Hybrid with Entra Connect:in a hybrid setup, Entra Connect syncs on-prem objects up to the cloud, but a cloud-only dynamic group cannot write back to an on-prem AD group. ServiceChanger drives the cloud side directly and runs a PowerShell runbook on a hybrid worker for the on-prem side, then lets your existing Entra Connect handle the sync direction it already handles.
• Where Conditional Access fits (context only):Conditional Access in Entra ID often keys its policies off group membership: "members of this group must satisfy MFA". Correct, attribute-driven membership makes those policies target the right people. ServiceChanger does not configure Conditional Access; it keeps the groups those policies read accurate.
• Where Intune fits (context only):Intune assigns device configurations and app deployments to groups. If those groups are attribute-driven, a new hire in a given department lands in the right deployment group automatically. ServiceChanger manages the group membership Intune targets, not the Intune policies themselves.

IAM requirements from NIS2 and ISO 27001

Access management is where a lot of the audit work lands, because NIS2 and ISO 27001 both ask you to prove, not just claim, that access is controlled. Attribute-driven memberships make three common requirements much easier to satisfy.

• Least privilege you can demonstrate:both frameworks want access limited to what a role needs. When a membership exists because "department = Finance", the justification is the attribute value itself, which turns least privilege from a claim into something you can point at.
• An audit trail:auditors want to see who had which access and why. Attribute-driven memberships give a consistent, explainable reason for every group, so the evidence is the mapping plus the attribute value rather than a pile of ad-hoc decisions.
• Periodic access reviews:both standards expect access to be reviewed on a schedule. Reviews go faster when every membership traces back to an attribute, because the reviewer checks the mapping once instead of every individual grant. ServiceChanger does not run the certification workflow itself; it makes the data that workflow reviews clean and consistent.

Common mistakes in access management

Most access problems are not technical, they are process problems that pile up over years. These are the six we see most, and every one of them is what attribute-driven memberships are meant to prevent.

• Copying rights from a colleague:the fastest way to grant access is to clone what the person next to you has, and it is also how permissions spread with no reason attached. Two years later nobody knows why half the group memberships exist.
• Trying to do everything in one project:teams try to model every department, exception and edge case before going live, and the project stalls. One clean department in production beats a perfect model that never ships.
• Not cleaning the attributes first:mapping on top of dirty data means "Finance", "finance" and "FIN" each get their own set of groups. The mapping looks broken when the data is the problem.
• No owner per group:a group with no owner is a group nobody reviews. When an access review asks "why does this exist", an unowned group has no answer and lingers for years.
• Not recording exceptions:the one person who needs extra access "just this once" becomes permanent silent drift when the reason is never written down. Every exception needs an owner and a reason on record.
• Forgetting offboarding:access that is granted on a schedule but only removed by hand always lags. When memberships follow attributes continuously, a leaver losing their attributes drops the access with them, instead of it sitting active for months.

FAQs on identity and access management (IAM)