An authority baseline is the current, trusted reference point for how access should be structured across identities, systems, and credentials. It is the benchmark against which drift is measured, and it must be refreshed when major business or technical changes alter the access landscape.
What an authority baseline establishes
An authority baseline is the trusted access reference point for a given environment, describing how privileges, entitlements, credentials, and account relationships should look before drift appears.
Its job is not to freeze access forever. It captures the current intended state so teams can compare live permissions and trust relationships against an agreed benchmark and spot when reality has moved.
This makes the concept useful in identity governance, privilege review, and configuration control, because the baseline must reflect the access model the organisation actually wants to defend, not just the one that happened to exist last month.
How it differs from a policy, inventory, or snapshot
An authority baseline is narrower than a broad policy and more operational than a simple inventory. Policy says what should be true in principle; the baseline records the concrete access structure that is currently treated as trusted.
It also differs from a point-in-time snapshot. A snapshot only shows what existed at one moment, while a baseline is maintained as the comparison standard used to identify meaningful drift over time.
That distinction matters because access systems change for legitimate reasons, such as reorganisations, mergers, cloud migrations, new applications, or changes in trust boundaries. The baseline is the reference that tells you whether those changes were intentional and approved.
What belongs in the baseline
A useful authority baseline usually spans who can access what, through which credentials or trust paths, and under what structural constraints. In practice, that can include user groups, privileged roles, service accounts, tokens, certificates, delegated access, and system-to-system relationships.
The baseline should be specific enough to reveal privilege creep and stale access, but not so brittle that normal business change constantly makes it obsolete. The best baselines capture meaningful access structure, ownership, and control boundaries rather than every transient implementation detail.
Where access is tied to production systems or shared platforms, a baseline also needs to account for inherited privilege and administrative dependencies. Those relationships are often where drift hides, especially after emergency access, manual fixes, or platform changes.
Why authority baselines matter for access drift
The practical value of an authority baseline is that it turns access review into a comparison problem. Instead of asking only whether access exists, teams can ask whether the access still matches the trusted model and whether any new path has appeared without approval.
That helps surface over-entitlement, abandoned access paths, shadow trust relationships, and changes introduced by automation or integration work. A strong reference point also makes it easier to separate real risk from harmless noise during review.
For baseline-oriented hardening, the CIS Benchmarks are a useful reference because they formalise secure configuration baselines that help keep system state aligned with trusted settings.
When an authority baseline must be refreshed
Authority baselines degrade when they are left tied to old architecture or old operating assumptions. Major business events, technical rewrites, cloud migrations, identity platform changes, outsourcing, and emergency access patterns can all invalidate the old trusted picture.
Refreshing the baseline is therefore not a cosmetic exercise. It is a governance action that re-establishes what “normal” access means after the environment has changed, so future drift checks remain meaningful.
When the baseline is not updated, teams often end up chasing false positives, missing stale privilege, or treating an outdated access model as if it were still authoritative.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Defines managed account state that an authority baseline compares against. |
| AC-6 — Least Privilege | Authority baselines are used to measure whether standing access exceeds intended privilege. | |
| CM-2 — Baseline Configuration | Authority baselines align with the control concept of approved baseline state for comparison. | |
| Recommendation — Record approved account structures and review drift against the current trusted baseline. Compare live access to the baseline and remove privileges that exceed intended need. Maintain an approved baseline and detect unauthorized changes from that reference state. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Configuration management requires controlled baselines and review of changes to trusted state. |
| Recommendation — Keep the trusted access baseline under change control and validate deviations promptly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account management covers the control of account state and access drift that baselines track. |
| Recommendation — Use account management reviews to reconcile access against the trusted baseline. | ||
Related resources from NHI Mgmt Group
- What is the difference between identity governance and authority governance?
- What is the difference between access visibility and access authority?
- What is the difference between delegated user access and machine authority for AI agents?
- What is the difference between delegated access and agent authority?