Identity Lifecycle Management: The Complete Guide to JML for Mid-Market IT
Why "lifecycle" is the part everyone gets wrong
It's Monday morning. Three new hires start today. One needs Salesforce. The other two need Jira and a Microsoft 365 E3 license. All three need the marketing-team SharePoint site. Or maybe two of them are in sales, not marketing, and you already half-remember that fact from a Teams message last Wednesday.
Now multiply that. The four people who changed roles last month. The contractor who finished on Friday. The developer who quit yesterday.
That's identity lifecycle management. The full motion of accounts and access through your environment, from day one to day done. Most mid-market IT teams do it manually. Most don't realize how much of their week it eats.
This is the long version of the guide. If you've got 50 to 1,000 employees on Microsoft Entra ID, this should cover what ILM means. What the joiner-mover-leaver framework looks like in practice. Where the gaps usually are. And the rough order to fix them.
What ILM actually is
ILM is the discipline of managing user accounts and their access from the moment a person joins the organization until they leave. It covers three workflows.
Joiner. Someone joins. They get the accounts, the licenses, the group memberships, and the SaaS app access that match their role. By day one. Without three back-and-forth emails to IT.
Mover. Someone changes roles. They get the new access for the new role. The old access from the previous role goes away. Both halves matter.
Leaver. Someone leaves. Their access is revoked completely, their licenses are reclaimed, their files are transferred, and the timeline is documented.
That's the whole framework. Joiner-mover-leaver, or JML. Three workflows. Applied consistently across the whole employee base. A paper trail an auditor can read in five minutes.
Vendors put fifty-page diagrams around this because the field traditionally served enterprises. Twenty HR systems, fifteen identity stores, and a federation layer. Mid-market companies aren't that. You have one HR system (probably). One identity store, which is Entra ID. A handful of SaaS apps reachable through it. ILM for you is simpler. Don't let anyone over-complicate it.
Why mid-market companies need it earlier than they think
There's a temptation to assume ILM is something you worry about at 1,000 employees. It isn't.
The actual threshold is more like 100. The math:
A 100-person company turns over roughly 10 to 15 percent of staff a year. That's 10 to 15 leavers. New hires usually match or exceed that, plus the moves and role changes. Total JML events: 30 to 50 per year for a 100-person company.
A 300-person company is doing 90 to 150 JML events per year. That's three a week, every week. And each event has multiple steps. License assignment. Group membership. SaaS app access. Mailbox setup. Group cleanup. Mailbox conversion. Asset return.
Manual ILM at that volume isn't dangerous because of any single mistake. It's dangerous because of cumulative drift. Every missed offboarding step becomes a dormant account waiting to be compromised. Every "we'll clean up the group memberships later" becomes access creep that an auditor finds eighteen months later.
Most mid-market companies look at ILM and say "later" because they don't measure the time it's taking. A 45-minute offboarding done 25 times a year is 19 hours. A 30-minute onboarding done 30 times is 15 more. Per role change, call it 20 minutes times 30 events, that's another 10 hours. Total: 44 hours a year on JML clicks alone. That's a full week of your time.
The joiner workflow
A clean joiner workflow does five things on day one.
Account creation. Entra ID account exists with the right UPN, display name, employee ID, department, and manager attribute. If hybrid, the on-prem AD account is synced too.
License assignment. The right Microsoft 365 SKU is on the account. Often this should be group-based licensing rather than direct assignment, because group-based licensing scales where direct assignment doesn't.
Group membership. The user is in the security groups, Microsoft 365 groups, and distribution lists their role needs. The trick is defining what "their role needs" means, and codifying that. Dynamic groups based on department or job title handle a lot of this automatically.
SaaS app access. If you're using Entra ID enterprise applications with SCIM or SAML, the right apps are assigned. The user lands in Salesforce, Jira, GitHub, or whatever else with no extra ticket.
A working email and a welcome message. Their first email exists. Their manager knows the account is ready. Nobody is wondering at 09:15 whether IT got the request.
The gold standard: HR system fires a "new hire" event. Identity tooling consumes it. All five steps happen automatically. A Slack or Teams message confirms it to the new hire's manager.
The bronze standard, which is most mid-market companies today: HR emails IT. IT clicks through the Entra ID admin center. Sometimes things get forgotten. The new hire's first day involves an "I can't get into SharePoint" ping.
The mover workflow
Mover is the workflow most companies skip entirely. They handle joiner and leaver. Moves are treated as "the user already has access, the new manager will sort it out."
That's how access creep is born.
A clean mover workflow does three things when a role changes.
Add the new role's access. Group memberships, SaaS apps, license tier if it differs. Same logic as a joiner, applied to the new role.
Remove the old role's access. This is the part that gets skipped. The previous manager's groups, the previous project's SharePoint sites, the previous tool stack. If you don't remove them, they accumulate forever.
Update reporting attributes. Manager, department, job title in Entra ID. These attributes feed dynamic groups, Conditional Access, license assignment, and downstream HR data. Don't leave someone listed under the wrong manager for six months because nobody pushed the update.
A 200-person company has roughly 25 to 40 role changes per year. Half a job's worth of clicks if you do it manually. Half of those changes will leave residual access behind if nobody enforces the cleanup.
The shortcut, where possible, is to drive most access from user attributes. Department, job title, location. When the attribute changes, the access changes with it. Dynamic groups in Entra ID handle the technical side, though the gotchas around attribute data quality are real.
The leaver workflow
Leaver is the riskiest part of the lifecycle. Miss a step here and you end up with a dormant account that still has access to your finance share. That's not a hypothetical. It's how a lot of breaches start.
A clean leaver workflow does ten things in order. The full Entra ID offboarding checklist walks through every step. The headlines:
- Disable the account immediately.
- Revoke active sessions.
- Reset the password (yes, even though the account is disabled).
- Remove group memberships.
- Remove application assignments and licenses.
- Check Conditional Access exclusions and clean them up.
- Convert the mailbox to shared or set forwarding.
- Transfer ownership of files, SharePoint sites, Power BI reports, Azure resources.
- Document the whole thing.
- Delete the account after the retention window.
Forty-five minutes per leaver if you're focused. An hour or more if you're switching between admin portals. Every one of those steps is a chance to forget something.
The "make it harder to forget" answer is automation tied to HR data. The HR system signals departure. The identity tooling runs all ten steps in sequence. An audit log records every action.
The "good enough for now" answer, if you can't automate it yet: a paper checklist plus a same-day enforcement rule. Account disabled within an hour. Sessions revoked at the same time. Groups and licenses cleaned within four hours. Mailbox conversion and file transfer within the day. Hard cutoff: if the leaver is high-risk, the work happens immediately. A departure that wasn't friendly, or someone with privileged access. Second person verifies.
Where the data has to come from
You can't run ILM without an authoritative source of joiner, mover, and leaver events.
For most mid-market Nordic companies, the source is the HR system. Personio, BambooHR, HiBob, Sympa, Hailey HR, Visma, whatever you're running. The HR system knows when someone is hired, when they change role, and when their last day is.
The integration story varies. Some HR systems have native Entra ID provisioning, where they push user data directly. Others surface webhooks or APIs you can wire up yourself. The simplest approach: make HR the authoritative source for the attributes that drive identity decisions. Department, job title, manager, employee ID, start date, end date. Let your identity layer consume those.
If you don't have a real HR system, the next best source is a shared spreadsheet that IT and HR both update. That's not ideal, but it's better than email threads. The point isn't the tool. The point is that someone outside IT owns the answer to "is this person still employed."
Compliance pressure on ILM
NIS2, ISO 27001, SOC 2, GDPR. They all push on ILM in the same direction.
NIS2 specifically calls for proper access control, timely revocation when access is no longer needed, and proper documentation. The NIS2 compliance checklist gets into this. The bullets that matter for ILM:
Automate user provisioning and deprovisioning. The directive uses softer language ("appropriate policies") but the audit reality is that manual offboarding doesn't pass.
Conduct regular access reviews. Quarterly for high-risk groups, annually for everyone else. Without ILM data, these reviews are guesswork.
Maintain audit logs. Every access change should be logged with who, what, when, and (ideally) why. Logs feed both incident response and audits.
ISO 27001 Annex A includes similar controls, particularly A.9 (Access Control) and A.7 (HR Security). SOC 2's Common Criteria 6 (Logical and Physical Access Controls) maps to the same workflows.
Your auditor asks "how do you ensure timely revocation of access." The answer is "we do it manually." You'll spend the rest of the audit defending it. With proper ILM, the answer is "here's the audit log." Every leaver documented with timestamps and the responsible IT engineer. That conversation takes ten minutes. The manual answer takes two days.
How ILM connects to your SaaS apps
The Entra ID half of ILM is one piece. The other piece is the long tail of SaaS apps where people actually do work. Salesforce, HubSpot, GitHub, Slack, Notion, Jira, Atlassian, Datadog, the finance tool, the HR tool. Each of those is a separate access surface.
Two patterns work for connecting them. SCIM (System for Cross-domain Identity Management) is the modern standard. Modern SaaS apps support it. When a user is provisioned in Entra ID, SCIM pushes the account to the SaaS app automatically. When the user is deprovisioned, SCIM tears it down. No tickets. No manual access requests.
SAML and OIDC handle the authentication side. Same idea, slightly different scope. SAML or OIDC mean the SaaS app accepts Entra ID as the identity provider. Login goes through Entra ID. No separate password.
The trick is using both together. SAML or OIDC for auth, SCIM for lifecycle. If you only have auth integration, the user can log in but the SaaS app doesn't know when to remove them. If you only have lifecycle integration, you're managing two sets of credentials.
For apps that don't support SCIM (the older SaaS apps, or anything self-hosted), you'll need a custom provisioning script or accept that those apps are manual. Make a list. Know which ones are manual. Don't pretend they're handled when they aren't.
What your HR data actually has to look like
ILM lives or dies on the quality of your HR data. Six attributes need to be reliable.
Employee ID. A stable identifier that doesn't change when someone's name or email changes. Use this as the join key between HR and identity systems, not the email address.
Department. Specific enough to drive group assignments. "Engineering" is not specific enough at a 300-person company. "Engineering - Backend" or "Engineering - Frontend" might be. Decide your level of granularity and apply it consistently.
Job title. Used for SaaS app assignment and (sometimes) for license tier. Be consistent. "Senior Software Engineer" and "Sr. Software Engineer" are the same job, but your rules will treat them differently if you don't normalize.
Manager. The reporting line, by employee ID (not by name). Used in mover detection, access reviews, and approval workflows.
Start date and end date. Both should exist on every record. Start date triggers provisioning. End date triggers deprovisioning. Without an end date, the leaver workflow can't run.
Employment type. Full-time, contractor, intern, vendor. Different employment types get different access patterns. Conflating them is how contractors end up with five-year-old Entra ID accounts.
If your HR system is missing one of these or stores it as a free-text field, your ILM will have gaps. Fix the HR data before building the workflows on top of it. The order matters.
Common ILM mistakes
A few patterns we see often.
Treating provisioning and deprovisioning as separate problems. They're the same problem in reverse. The same rules that add access on day one should remove it on the last day. If your onboarding is automated and your offboarding is manual, you'll always have an offboarding backlog.
Letting "temporary access" become permanent. A user covers for a colleague on parental leave. Gets temporary access to a finance group. Colleague comes back. Temporary access stays. After two years, half your access list is "temporary."
Forgetting non-employees. Contractors. Vendors. Auditors. Interns. They're often given full Entra ID accounts (sometimes guest accounts), and the JML workflow only covers employees. Their offboarding falls through the cracks. Set expiration dates on every contractor account at creation time. Force a review before extending.
No retention strategy. What happens to a leaver's OneDrive after their account is deleted? Their mailbox? Their Power BI reports? If you don't have answers, you're either losing data or paying to store everything forever. Decide upfront. Document it. Apply it consistently.
One person knows the playbook. Your senior sysadmin knows exactly what to do for an offboarding. They've never written it down. They go on vacation. A leaver happens that week. Three people guess at the steps. Two of them get skipped. Document the workflows, even if the documentation looks tedious. Vacation coverage is a real ILM risk.
Skipping the audit log. Every JML action should be logged. Who triggered it, what changed, when. Without that log, the audit becomes a memory test. With it, the audit becomes a fifteen-minute conversation.
Measuring ILM, briefly
If you're not measuring, you don't know if it's working. Four metrics worth tracking at a 200-person company.
Time to first sign-in for a new hire. Target: same day. If it's three days, your joiner workflow has a queue problem.
Time from termination to full deprovisioning. Target: under four hours. If it's a week, your leaver workflow has a coverage problem.
Number of orphaned accounts in the directory. Target: zero. If you can't find any, look harder. They exist.
Percentage of access changes captured in the audit log. Target: 100 percent. Anything missing is an audit risk.
You don't need a dashboard. A monthly check-in on these four numbers is enough to know whether ILM is healthy.
How to build ILM without a six-month project
Three rough phases. Each one builds on the previous one. You don't need a vendor for any of this, except to skip the slow parts.
Phase one: get the data straight. Pick your authoritative source (HR system, ideally). Make sure the attributes you need are reliably present and correctly populated. Department, job title, manager, employee ID, dates. If half your users have "department" as "Marketing" and half as "marketing," fix that before anything else. The whole rest of ILM depends on attribute data quality.
Phase two: define the workflows on paper. Map out exactly what should happen for a joiner in marketing vs sales vs engineering. Same for movers. Same for leavers. Write these down. It's tedious. It's also the basis for everything that comes next.
Phase three: automate the high-volume parts first. Joiner provisioning is usually the easiest win. Offboarding is the highest-risk win. Movers are the slowest to automate properly because role transitions are rarely clean. Pick the workflow that hurts most and start there.
You can build phase three with Microsoft tooling if you have the right licensing and the time. Entra ID Governance, Power Automate, PowerShell, Logic Apps. The pieces exist. The integration work is the slow part.
Or use a tool designed for this specifically. That's the case we made in our deploy-in-a-day post. Different answer for different companies.
Build vs buy, honestly
At some point you decide whether to build the ILM automation in-house or buy a tool. There's no universal answer. Three rough signals worth using.
Build makes sense when your IT team has real engineering capacity, your environment is simple (one HR system, one identity store, a handful of well-behaved SaaS apps), and your compliance needs are modest. PowerShell, Logic Apps, Power Automate, and a few webhooks will get you a long way. The downside is ownership. You wrote it, you maintain it, you debug it on a Saturday when it breaks.
Buy makes sense when your IT team is small and busy, the workflow needs to support audits (which means real audit logs and reporting), and the cost of someone slipping through the cracks is high. Buying gets you the workflow plus the audit trail in a week. You give up some customization in exchange.
The wrong answer is buying enterprise IGA when you only need mid-market ILM. SailPoint, Saviynt, and One Identity were designed for environments with 5,000 users and twenty HR systems. We've written about the right-sizing problem at length. The short version: if you're a 200-person company, an enterprise IGA platform will take six months to deploy, cost more than two engineering hires, and use 15 percent of its features.
There's a middle layer of tools (Adcyma included, full transparency) built specifically for the mid-market shape. One HR system, one Entra ID tenant, the long tail of SaaS apps brokered through it. If that's your shape, a mid-market tool will fit better than either pole.
What "good" ILM looks like in practice
A 250-person Nordic company with ILM running properly looks something like this.
HR system flags a new hire on Friday. By Monday morning, the new account exists in Entra ID with the right department and manager attribute. Group memberships are assigned automatically. License is on. The right SaaS apps are provisioned. The manager gets a confirmation message in Teams. The new hire logs in at 09:00 and starts working.
A role change happens. HR updates department and job title. The old groups drop off within an hour. The new groups attach within the same hour. Reporting attributes flow downstream into Conditional Access and license assignment. Nobody opens a ticket.
A leaver is flagged. The account is disabled within minutes of the HR record update. Sessions revoke. Licenses release. Groups strip. The mailbox converts to shared and forwards to the manager. The OneDrive contents transfer to the manager. The audit log captures every step with a timestamp and the engineer (or workflow) responsible.
An audit happens. The auditor asks "what's your process for revoking access." The IT lead pulls up the dashboard, shows the audit log of the last 50 leavers, and the conversation is done in 20 minutes.
That's the target. Most mid-market companies are nowhere near it today. Getting there is a 6 to 12 month project at most, not a multi-year one. The pieces are not exotic.
Where Adcyma fits
Full transparency: this is our product, so take this with the appropriate context. Adcyma is built for the ILM gap in mid-market companies on Entra ID.
We handle the HR integration, the joiner-mover-leaver workflows, the access reviews, and the audit reporting. The provisioning happens through Entra ID, not in parallel to it, so your existing identity stack stays intact. The audit log is built in. The deployment is one day, not six months.
If your week involves hours of clicking through Entra ID for onboarding and offboarding, that's the gap. If your last audit involved screenshotting group memberships into Excel, also the gap. Free for up to 25 users. 14-day trial above that.