What should security teams review first in an identity provider programme?

What to review first in an identity provider programme

Security teams should begin with the parts of the IdP that determine whether access is actually well-shaped and quickly removed: role design, assertion scope, and offboarding. That is where you find overbroad entitlements, weak trust boundaries, and stale access that can survive far longer than it should.

Role design is the first lens because it shows whether the IdP is expressing business intent cleanly or simply accumulating access over time. If roles are vague, shared across too many applications, or mapped too broadly, the programme will keep issuing more access than users and systems genuinely need. That problem is architectural, not just administrative, because every downstream control inherits it.

Assertion scope is the second lens because it defines what the IdP sends into each application and, just as importantly, what it does not send. A well-run programme keeps assertions narrow, purpose-specific, and tied to the minimum claims needed for the relying party. If applications receive broad or reusable assertions, the IdP becomes a trust amplifier instead of a trust boundary. A useful baseline is to compare the programme against Identity Provider and SSO Security Guide and OpenID Connect Core 1.0, then verify that claims, tokens, and federation settings are constrained to the exact application use case.

Offboarding is the third lens because it shows whether the IdP removes trust fast enough when a person leaves, a role changes, or an account should no longer exist. Stale access is one of the clearest indicators that an identity programme looks healthy on paper but is leaking privilege in practice. Review deprovisioning speed, account disablement, token revocation, and any dependency on manual follow-up, because those are the places where excess access persists.

Why these three checks expose the real trust model

Role design, assertion scope, and offboarding together answer a basic question: does the IdP enforce least privilege, or does it merely centralise login? If the answer is the latter, the organisation may still have single sign-on and strong authentication, but it does not yet have disciplined access governance. That is why these checks belong before tuning federation, assurance levels, or secondary convenience features.

Role design reveals whether access decisions are understandable and reviewable. Assertion scope reveals whether applications are receiving a limited, auditable set of claims or a broad identity package that can be reused beyond intent. Offboarding reveals whether trust ends when it should, which is especially important where application sessions, API tokens, or delegated access survive account changes. When these three are weak together, the programme can look standardised while still leaving broad exposure in place. For a practitioner view of lifecycle and access governance, Workforce Identity Security Guide and Identity Security Programme Guide provide useful framing.

Teams should also treat this as a dependency check across the wider identity stack. A good IdP can still be undermined by weak role engineering, overly generous federation mappings, or slow lifecycle automation. That is why the first review should not start with feature breadth or vendor claims. It should start with whether the access model is tightly scoped, operationally enforced, and reversible when trust changes.

What good looks like in practice

Good role design keeps permissions intelligible, application-specific where needed, and limited enough that reviewers can explain why each role exists. Good assertion scope means the application receives only the claims it needs to make its own authorization decision, with no unnecessary identity data or broad privileges embedded in the assertion. Good offboarding means removal is triggered by source-of-truth change, not by a best-effort ticket, and that old credentials, sessions, and access paths are actually invalidated.

One practical test is whether an application can still function if you strip the assertion down to the minimum viable claims. If it cannot, the application may be depending on the IdP as an overextended authorization engine. Another test is whether a departed user or retired account can still reach any system through cached sessions, stale tokens, or unmanaged service access. If yes, the programme has an offboarding problem, even if the login flow itself appears modern.

This is why NHIMG’s perspective on identity programmes tends to emphasise lifecycle before sophistication. Better-looking federation does not compensate for poor role engineering or delayed deprovisioning. Review the controls that shrink access, not the ones that only make access easier to issue.

Practitioner Guidance

What to prioritise: Start with the roles and claims that map to production applications with the widest blast radius, then move to the offboarding paths that remove access from leavers, contractors, and de-scoped accounts. Those are usually the fastest ways to expose whether the programme is overissuing or under-removing access.

What to verify: Confirm that role changes, application claim mappings, and deprovisioning events are driven from authoritative sources and leave an audit trail. If the team cannot show when access was reduced, revoked, or expired, assume the control is weaker than it looks.

Common mistake: Treating the IdP as finished once sign-on works. Authentication success does not prove that role design is tight or that old access is disappearing on time. The programme is only healthy when access is both narrowly issued and promptly removed.

Practitioner takeaway: The first review should test whether the IdP is a trust boundary or just a login hub. If role design, assertion scope, and offboarding are weak, every later improvement is built on excess access that the programme has not yet controlled.

Related resources from NHI Mgmt Group

• How should security teams detect shadow app usage from identity provider logs without waiting on manual review?
• What should security teams do first after a SaaS identity provider compromise is suspected?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?