Most access request workflows approve almost everything, slowly, because the wrong person is asked the wrong question about an entitlement they cannot understand. The result is the worst of both outcomes: users wait days, approvers rubber-stamp, and auditors find that the approval trail proves nothing about need. Good workflow design decides what should be requestable at all, who is genuinely able to judge each request, how much scrutiny each risk level deserves, and how long access lasts. This guide covers catalogue design, approver selection, risk-tiered approval chains, service levels, rubber-stamping countermeasures, non-human identity requests and measurement. It is for IGA engineers, IAM product owners and control owners. Access reviews after the fact are covered in the Access Reviews Guide; this page is about the decision at the point of request.
Key takeaways
- The approver must be able to say no. An approval only has control value when the approver has the knowledge, the information and the independence to refuse; otherwise it is a delay with a signature.
- Tier approvals by risk. Low-risk access can be auto-approved or manager-approved; privileged, sensitive data and segregation of duties relevant access needs owner approval, justification and an expiry.
- Design the catalogue before the workflow. Requestable items need business-readable names, descriptions, owners and risk ratings, or no approval chain will work.
- Time-bound by default. Access that expires and must be extended removes most of the clean-up burden from reviews.
- Measure approval quality, not just speed. Approval rate, time to decision and how often approved access is ever used reveal rubber-stamping faster than any audit.
What a request workflow must achieve
NIST SP 800-53 AC-2 requires organisations to require approvals by defined personnel for requests to create accounts, to authorise access based on a valid access authorisation and intended system usage, and to define prerequisites for group and role membership. AC-5 asks for access authorisations that support separation of duties. The NCSC's identity and access management guidance asks organisations to define who can access which systems and why, and to identify actions that should require more than one person. A workflow meets these when it produces four things for every grant:
- A recorded business need: who asked, for what, why, and for how long.
- An informed decision: by someone accountable for the access or the person, with the information to judge it.
- Automated, accurate fulfilment: the exact entitlement approved, provisioned without manual re-keying.
- An end: an expiry, a review or a lifecycle trigger that removes the access.
Designing the request catalogue
Users request what they can understand. If the catalogue lists "GRP-FIN-SAP-ZFI_AP_POST_02", both the requester and the approver are guessing.
| Catalogue attribute | Purpose | Example |
|---|---|---|
| Business name and description | Lets requesters choose correctly and approvers judge | "Post supplier invoices in SAP (up to approval limit)" |
| Owner | The accountable approver for the access itself | Accounts payable manager |
| Risk rating | Drives the approval chain and expiry | High: financial transaction capability |
| Eligibility | Who may request at all | Finance department employees only |
| Incompatible access | Segregation of duties constraints | Cannot be held with "Create and amend supplier bank details" |
| Default duration | Time-bound access | 365 days, extendable with approval |
| Bundle membership | Packages of entitlements for a job task | Part of "Accounts payable clerk" package |
Request packages, not raw entitlements: bundle the groups, application roles and SaaS licences needed for a task into one requestable item. Microsoft Entra entitlement management calls these access packages; most IGA platforms have an equivalent. See the Entitlement Catalogue and Application Onboarding Guide and the Role Mining and Role Design Guide.
Birthright versus requestable: access every member of a population needs on day one (email, intranet, core collaboration) should be granted automatically by HR attributes, not requested. Requests should cover the exceptions. See the Joiner-Mover-Leaver Guide.
Choosing approvers
| Approver | What they can judge | What they cannot judge | Use for |
|---|---|---|---|
| Line manager | Whether the person's job needs it; whether they are still on the team | What a technical entitlement actually allows | First stage for most requests |
| Resource or data owner | Whether this access to this resource is appropriate; data sensitivity | The requester's role and workload | Sensitive data, production systems, privileged roles |
| Security or control owner | Policy, SoD conflicts, privileged access standards | Business need | Privileged and SoD-relevant access, exceptions |
| Sponsor (for external users) | Whether the contract or relationship still exists | Internal entitlement detail | Contractors, partners, guests |
| Policy engine (auto-approve) | Rule-based eligibility, such as department and job code | Exceptions and context | Low-risk access within eligible populations |
Approver design rules
- No self-approval: requesters must never approve their own access. Microsoft's entitlement management, for example, prevents approvers from approving their own requests.
- Fallbacks for missing managers: manager data is often wrong or empty; configure fallback approvers who receive the request when no manager is found, rather than letting it stall or auto-route to a generic queue. See the Identity Data Quality and Authoritative Sources Guide.
- Groups, not individuals, for owner approval: one named owner on holiday blocks everyone; a small owner group with a rule that any one member approves keeps the decision informed.
- Independence: for privileged access, the approver should not be in the same reporting line as the requester only, and should not be the person who will benefit from the work.
Risk-tiered approval chains
| Risk tier | Examples | Approval | Justification | Duration |
|---|---|---|---|---|
| Low | Team sites, standard SaaS for the department | Auto-approve for eligible population, or manager | Optional | Until role change |
| Medium | Business application roles, shared drives with internal data | Manager | Required | 12 months, extendable |
| High | Confidential data, finance transaction roles, production read | Manager then resource owner | Required, with ticket or project reference | 6 to 12 months |
| Privileged | Admin roles, production write, security tooling admin | Manager, resource owner, then security; activate just in time | Required; approver justification also required | Eligibility time-bound; activation in hours |
| Non-human identity | New service account, API client, agent permissions | Requesting owner, platform owner, security for privileged scopes | Purpose, systems reached, credential type | Bound to project or workload lifetime |
Multi-stage mechanics: Microsoft's entitlement management supports single-stage approval (any one listed approver decides) or multi-stage approval with first, second and third approvers, each stage with its own decision timeout and optional approver justification. If no decision is made in time, the request is denied and must be resubmitted. Alternate approvers can receive a request after a set number of days; Microsoft requires the stage timeout to be at least four days to use this. Other IGA platforms offer similar controls under different names.
Privileged access belongs in two decisions: approve eligibility for a role (who may hold it, for how long), then approve or self-activate each use just in time. See the JIT Access Guide and the Privileged Identity Management (PIM) Guide.
Segregation of duties at request time: block conflicting requests before approval rather than detecting them in a review. Microsoft's incompatible access packages and groups block requests from people who already hold the conflicting access, but the rule is one-way (configure both directions) and existing holders are not removed. See the Segregation of Duties Guide.
Service levels and expiry
- Set decision targets per tier: for example, one working day for low and medium, three for high and privileged. Slow approvals drive people to shared accounts and out-of-band grants.
- Escalate before expiring: forward to alternate approvers (such as a second-level manager) halfway through the timeout, then deny. A request that silently sits for weeks teaches users to go to the help desk instead.
- Do not auto-approve on timeout: timing out to approval turns inattention into consent. Time out to denial with a clear message.
- Default expiry: Microsoft's lifecycle settings allow assignments to expire on a date, after 0 to 3,660 days or a number of hours, or never; users can be allowed to extend, with reminder emails 14 days and 1 day before expiry, and extensions can require approval. Choose "never" only for birthright-like access.
- Re-approval on change: a mover event should trigger review or removal of requested access tied to the previous role.
Defeating rubber-stamping
Rubber-stamping happens when approvers lack information, time or accountability. Fix the causes:
- Show context in the approval: what the access allows in plain language, its risk rating, whether peers in the same role have it, whether it creates an SoD conflict, and the requester's justification.
- Reduce volume: auto-approve low-risk access for eligible populations so approvers see only decisions that matter.
- Require approver justification for high risk: a short reason changes behaviour and gives auditors evidence.
- Route to the right owner: a line manager approving a database admin role is not a meaningful control; add the resource owner.
- Feed usage back: report to each approver how much of the access they approved was used in the following 90 days.
- Sample and challenge: control owners periodically sample approvals for high-risk items and follow up on any that cannot be justified.
Requests for non-human identities
Service accounts, API clients and AI agents are often created by ticket with no structured request at all. Treat them as requestable items with their own form: owner and backup owner, purpose, systems and scopes required, credential type (prefer federation or managed identities over secrets), environment, expiry or review date and data classification. Microsoft's request policies can now include service principals and agents as eligible requesters through Microsoft Entra Agent ID, which shows the direction of travel: NHI access is joining the same governance process. See the NHI Ownership Guide and the Service Account Security Guide.
Implementation roadmap
- Baseline (month 1): measure today's request volumes, approval rates, time to decision and how often requests are fulfilled outside the workflow (direct group adds, help desk tickets).
- Catalogue the top 50 (months 1 to 3): rename, describe, risk-rate and assign owners to the most requested and highest-risk entitlements; build packages for common job tasks.
- Configure tiers (months 2 to 4): implement the approval chains, timeouts, fallbacks and expiry per tier in the IGA or entitlement management platform. Pilot with one department.
- Close side doors (months 3 to 6): alert on direct group and role changes made outside the workflow, and route help desk access requests into the catalogue. Keep an emergency path that is logged and reviewed.
- Extend (months 6 to 12): onboard more applications, add NHI request forms and connect SoD rules.
Rollback: keep the previous workflow active for in-flight requests and switch only new requests to the new policies, so a misconfigured chain can be reverted without losing pending approvals. Small organisations may not need an IGA platform: a ticketing form with mandatory fields, manager plus owner approval for high-risk items and scripted provisioning can meet the same principles. Large organisations should standardise tier definitions centrally and let application owners choose only within them.
Detection and measurement
- Out-of-band changes: group membership and role assignments made directly rather than by the workflow engine; Microsoft provides an "Application role assignment activity" workbook to show app role changes not made by entitlement management.
- Self-approval attempts and approver-requester relationships that breach independence rules.
- Help desk grants: access or MFA changes made by support staff on a phone call or chat, without a matching workflow request. Report these weekly to the control owner, check each against the caller verification record, and treat any privileged grant made this way as a potential incident until it is confirmed. See the Help Desk Social Engineering Incident Playbook.
| Metric | Healthy signal | Warning sign |
|---|---|---|
| Approval rate by tier | Lower for high and privileged tiers | Close to 100% everywhere |
| Median time to decision | Within tier service level | Very fast decisions on high-risk items (seconds) |
| Approved access unused after 90 days | Low and falling | High, showing access granted "just in case" |
| Access granted outside the workflow | Near zero, all emergency and reviewed | Regular direct grants by admins |
| Requested access with an expiry date | All medium and above | Most set to never |
| Requests stalled for lack of an approver | Near zero | Frequent, pointing to bad manager data |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 (approval of account requests, authorisation by need), AC-2(1) Automated System Account Management | Approval and automated fulfilment |
| NIST SP 800-53 Rev 5 | AC-5 Separation of Duties; AC-6 Least Privilege | SoD checks and least privilege at request |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined, managed, enforced and reviewed |
| CIS Controls v8.1 | 6.1 Establish an Access Granting Process; 6.8 Define and Maintain Role-Based Access Control | Process and roles |
| ISO/IEC 27001:2022 Annex A | A.5.15 Access control; A.5.18 Access rights; A.5.3 Segregation of duties | Policy, provisioning and SoD |
Common failure patterns
- Manager-only approval for everything: managers approve technical entitlements they cannot evaluate.
- Timeout to approve: requests auto-approve when nobody answers, so silence becomes consent.
- Entitlement names nobody understands: requesters ask for whatever a colleague has, approvers approve it.
- Permanent requested access: no expiry, so access accumulates across moves and reviews become unmanageable.
- Workflow with side doors: admins add people to groups directly "to save time", leaving the workflow as an audit artefact only.
- NHIs outside the process: service accounts and API keys created by email or chat with no owner or expiry.
Lessons from incidents
Workflows are only as strong as their exceptions. In the MGM Resorts breach, the attackers' own account is that a phone call to the help desk got them into the identity platform. Any route that grants access or resets authentication outside the approved workflow, however urgent the caller sounds, needs the same identity verification and logging as the workflow itself.
Practitioner checklist
- Give every requestable item a business name, description, owner, risk rating and default duration.
- Bundle common job tasks into packages; grant birthright access automatically.
- Define approval chains per risk tier, with resource owner approval for high and privileged access.
- Block self-approval and configure fallback approvers for missing managers.
- Time out to denial, with escalation to alternate approvers before the deadline.
- Apply expiry to all medium-risk and higher access, with approval required to extend.
- Check SoD conflicts at request time, in both directions.
- Route NHI creation through a structured request with owner, scope and credential type.
- Alert on access granted outside the workflow.
- Report approval rate, time to decision and unused approved access to control owners monthly.
Standards and references
- NIST: SP 800-53 Rev 5 Security and Privacy Controls (AC-2, AC-5)
- NCSC: 10 Steps, Identity and access management
- Microsoft: Change approval settings for an access package
- Microsoft: Change request settings for an access package
- Microsoft: Change lifecycle settings for an access package
- Microsoft: Configure separation of duties checks for an access package
Related NHI Mgmt Group resources: Access Reviews Guide · Entra ID Entitlement Management and Access Packages Guide · Segregation of Duties Guide · IGA Buyer's Guide · Identity Data Quality and Authoritative Sources Guide