Because billing and entitlement are not the same thing. Per-user licences can leave dormant accounts on the books, while per-active-user models can hide sharing and weaken accountability. Access reviews need identity ownership, usage evidence, and lifecycle status, otherwise the review certifies a commercial seat rather than a legitimate access decision.
Why per-user pricing breaks the access review model
Per-user SaaS licensing looks simple until access governance has to prove who should still have access. A licence tells you who is billed, not who is entitled, active, approved, or accountable. That gap matters because reviewers can end up certifying seats, not legitimate access. In practice, billing records are a poor substitute for identity ownership and lifecycle status.
Per-user models also create false comfort. An account may remain licensed long after the employee has changed roles, stopped using the product, or left the business, and the presence of a paid seat can make the access review appear clean. The review then misses dormant accounts, orphaned access, and excess entitlement because commercial status is mistaken for control status.
When organisations rely on usage alone, the opposite problem appears. Per-active-user licensing can encourage account sharing, pooled logins, and one person using another person’s seat. That can reduce accountability and blur the review signal, because the question becomes whether the seat was used, not whether the named identity should have access. IAM and IGA Basics is useful here because the core issue is the distinction between entitlement, review, and actual identity control.
What access reviewers actually need to verify
Access review quality depends on three separate checks: identity ownership, usage evidence, and lifecycle state. Ownership answers who is responsible for the account or entitlement. Usage evidence shows whether the access is being exercised in a way that matches the business need. Lifecycle state shows whether the person or non-person behind the account is still active, on leave, transferred, or offboarded. Without all three, the reviewer is making a commercial judgement, not a security one.
The strongest review process ties each SaaS account back to an authoritative source of truth, then asks whether the account is still needed for the current role or workflow. This is where periodic recertification often fails, because the reviewer sees a list of named users and approved seats but not the operational reality behind them. Access Reviews and Certification Guide directly supports the need to design reviews so they remove access, not just confirm spend.
Licence status can still be useful evidence, but only as context. A paid seat may support that an account exists and is budgeted for, yet it does not prove active legitimacy. A good review distinguishes between “licensed”, “used”, and “allowed”, then treats gaps between those states as a signal for follow-up rather than an automatic approval.
Why lifecycle discipline matters more than licence counts
Per-user SaaS environments become hard to review when offboarding, transfers, and temporary access are handled outside a lifecycle process. If access is granted in one system, billed in another, and reviewed by a manager who only sees a roster export, the organisation loses the chain of accountability. NHI Lifecycle Management Guide is relevant because the underlying governance problem is lifecycle state, regardless of whether the subject is human or non-human.
That same lifecycle gap creates review drift over time. A SaaS account can look valid because it is still attached to a subscription, even though the original business justification expired months earlier. If the review process does not explicitly test for joiner, mover, and leaver events, it will miss the difference between an account that is merely funded and one that is still authorised. Joiner-Mover-Leaver (JML) Guide helps frame why access removal must follow employment and role changes, not billing renewals.
At scale, the problem is not just noise, it is misclassification. Hundreds of “valid” licences can conceal an access model that has drifted away from actual business need. The result is either excessive approvals or expensive cleanup after a control failure. Identity Visibility and Intelligence Platforms (IVIP) Guide adds value where teams need a fuller view of effective access rather than just contractual entitlements.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Per-user SaaS reviews depend on keeping accounts current and removing stale access. |
| Recommendation — Audit SaaS accounts routinely and remove dormant or unneeded access. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | This issue is about account lifecycle, review, and removal of stale entitlements. |
| IA-5 — Authenticator Management | SaaS review problems often hide behind reused or lingering credentials tied to active seats. | |
| Recommendation — Review account status against business need and disable accounts no longer required. Rotate or revoke authenticators when account purpose or ownership changes. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be reviewed against current need, not billing status. |
| Recommendation — Periodically recertify access rights and remove those no longer justified. | ||
| OWASP ASVS | V8 — Authorization | The core failure is certifying entitlement as if it were legitimate authorization. |
| Recommendation — Verify that granted access matches current authorization intent before approval. | ||
Practitioner Guidance
What to prioritise: Review SaaS access by named identity and current business purpose, not by licence utilisation. If a person can no longer explain why the account is needed, the licence should not be the deciding factor.
What to verify: Require evidence from three places before certifying access: the SaaS roster, the authoritative HR or workforce source, and recent usage or activity evidence. If those records disagree, treat the account as a follow-up item, not a clean approval.
Common mistake: Teams often let “paid seat” become shorthand for “approved access”. That shortcut hides dormant accounts, account sharing, and stale entitlements, which are exactly the conditions access reviews are supposed to surface.
Practitioner takeaway: The review should answer “should this identity still have access?”, not “does the organisation still pay for it?”. When billing and authorisation are conflated, access certification becomes a finance check with security language.