Baseline

Expanded Definition

In NHI security, a baseline is the approved reference state for a service account, API key, secret store, policy set, or agent configuration. It is not just a snapshot of what exists today. It is the state that teams agree to measure drift against, so they can tell whether a non-human identity has changed in an authorised or risky way. For that reason, a baseline must include ownership, expected privileges, rotation settings, and monitoring hooks.

Baseline management is closely related to configuration management, but it is narrower and more operational in NHI programs. A general configuration record may describe many assets, while a baseline must define what “good” looks like for a specific identity or control plane. In standards-oriented practice, this fits naturally alongside NIST Cybersecurity Framework 2.0, especially where organisations need repeatable detection and response around asset state.

Definitions vary across vendors on whether a baseline is only a technical configuration or also includes governance metadata such as approval owner, expiry, and exception handling. NHI Management Group treats those governance fields as part of the operational baseline because they determine whether the identity can be safely trusted over time. The most common misapplication is treating a baseline as a one-time setup artifact, which occurs when teams stop updating it after deployment or rotation changes.

Examples and Use Cases

Implementing baselines rigorously often introduces maintenance overhead, requiring organisations to balance faster delivery against the cost of keeping the reference state accurate.

• A service account baseline records its owning application, expected API scopes, approved vault location, and last rotation date, then alerts when any of those elements drift.
• An agent baseline defines which tools it may call, what prompts or policies govern it, and which secrets it may access, so security teams can detect unauthorised expansion of capability.
• A secrets baseline marks whether a credential must live only in a managed vault, aligning with guidance in the Ultimate Guide to NHIs on visibility, rotation, and offboarding.
• A cloud workload baseline compares deployed IAM permissions against the approved least-privilege profile and flags any manual exception that was added during incident response.
• A CI/CD baseline tracks token usage, repository access, and environment bindings, then verifies that changes are reflected before the next release pipeline runs.

For implementation detail, the baseline is usually paired with policy checks and inventory systems rather than used alone. That is consistent with NIST Cybersecurity Framework 2.0 practices that depend on current visibility before control can be enforced.

Why It Matters in NHI Security

Baselines matter because NHI environments drift quickly. Secrets get copied into code, service accounts accumulate permissions, and agent tool access expands during troubleshooting. Without a current baseline, teams lose the ability to distinguish approved change from exposure. That is especially dangerous in NHI programs, where one stale credential can outlive the intended system change and remain silently usable. The Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which makes baseline discipline essential for detecting entitlement creep before it becomes an incident.

A weak baseline also undermines audits and incident response. If there is no agreed reference state, defenders cannot prove whether a token, certificate, or workload identity was expected to exist, much less whether it should still be active. That leads to slower containment, messy exception handling, and inconsistent remediation. For governance teams, the baseline becomes the practical evidence that lifecycle controls, rotation, and ownership are actually enforced rather than merely documented.

Organisations typically encounter baseline failure only after a breach review or failed audit, at which point the baseline becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why does leaving Linux outside the passwordless baseline increase identity risk?
• When should organisations expand beyond the baseline controls in NIST 800-53?
• How should teams govern internal mTLS when TLS 1.3 becomes the baseline?
• Behavior Baseline