What should IAM teams do when certifications cover users, partners, and systems?

Why segmented certification reviews work better than one broad campaign

When a certification touches users, partners, and systems, the review should be split into reviewable populations that share a similar business purpose, risk profile, and approver. That keeps the reviewer’s decision anchored in context instead of forcing one person to assess unrelated access patterns at once. It also makes exceptions easier to justify and track, instead of letting them disappear in a large, noisy campaign.

Segmenting does not reduce the security standard. It improves the quality of the decision by giving reviewers a clearer basis for judging whether access is still required, whether the entitlement is oversized, and whether the access path is even owned by the same team. In practice, this is why many access-review programmes pair access certification with Access Reviews and Certification Guide and IAM and IGA Basics rather than treating every certification as a single company-wide event.

A useful rule is to group by business context first, then by control owner, then by risk. For example, employee access, external partner access, and system or service access usually need different evidence, different reviewers, and different remediation paths. That is especially true when the population includes accounts with different lifecycle rules, different ownership models, or different downstream blast radius. A certification only works when the reviewer can answer the question that belongs to that access type.

What to separate in practice

IAM teams should separate certification by the dimension that changes the review decision. In most environments that means at least three practical buckets: human workforce access, third-party or partner access, and system or workload access. Those groups tend to differ on ownership, approval authority, expiry expectations, and the kind of evidence a reviewer needs to trust the record.

• Human access is usually reviewed against role, job function, and manager accountability.
• Partner access is usually reviewed against contract scope, sponsor ownership, and time-bound need.
• System access is usually reviewed against application ownership, service purpose, and technical dependency.

This separation is also where lifecycle discipline matters. A certification campaign is stronger when it aligns with the underlying identity lifecycle, because reviews that uncover stale access should flow into revocation, rotation, or offboarding rather than becoming a report-only exercise. The same principle underpins Joiner-Mover-Leaver (JML) Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs, which both tie review decisions to downstream removal or renewal actions.

For environments with many service identities or machine accounts, segmentation also helps avoid false equivalence. A system account that exists to run an integration is not reviewed the same way as an employee with interactive access. Bringing them into one queue usually produces rubber-stamping, because the reviewer cannot apply the same decision logic to both.

How to keep the review defensible, not just smaller

The goal is not to minimise the number of reviews at any cost. The goal is to make each review defensible by reducing the cognitive load on the approver and preserving the context needed for a sound decision. That means the campaign design should surface the access owner, the business purpose, the entitlement scope, the start date, and any material exception history in the same workflow.

Where certification spans multiple populations, the strongest programmes also align the segmentation with role design and segregation of duties. If a reviewer is being asked to approve access that crosses functional boundaries, the campaign should make that conflict visible rather than hiding it inside a long list of unrelated entitlements. Resources such as Role Mining and Role Design Guide and Segregation of Duties (SoD) Guide support that same design principle: review access in the structure that makes conflict, ownership, and risk visible.

Teams should also watch for campaign design that mixes high-volume operational access with low-volume privileged access. That creates reviewer fatigue and weakens decision quality, especially when the same approver is expected to assess both routine and high-impact entitlements in one pass. A segmented model preserves attention for the cases where a mistake matters most.

Practitioner Guidance

What to prioritise: separate the certification by reviewer decision, not by directory structure. If two access types would not be approved for the same reason, they should not sit in the same review queue.

What to verify: each segment should have a clear owner, a clear remediation path, and a clear rule for when a reviewer can approve, reject, or escalate. If the workflow cannot show who can act on the result, the certification is too coarse.

Common mistake: treating a large campaign as more complete because it is broader. Broad campaigns often increase missed exceptions, because the approver optimises for speed instead of evidence.

Practitioner takeaway: a defensible certification is one that matches the way access is actually used and governed, so the review stays meaningful when it reaches the people who must own the decision.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?