Configuration Baseline

The approved reference state for a system, policy, or controlled asset. A baseline defines what the environment should look like after a legitimate change. Security teams use it to compare current state against intended state and to spot drift, tampering, or incomplete implementation.

Expanded Definition

A configuration baseline is the approved, documented state of a system, policy, or controlled asset that defines what “correct” looks like after an authorised change. In NHI and IAM operations, baselines are used to compare current state against intended state so teams can detect drift, tampering, missing controls, or incomplete rollouts.

For non-human identities, the baseline can include service account scope, token lifetime, rotation settings, vault location, allowed destinations, and logging requirements. That makes it different from a generic configuration snapshot because it is not just descriptive, it is normative. The baseline becomes the reference point for change control, incident response, and continuous compliance. This aligns with the control-and-monitoring approach used in the NIST Cybersecurity Framework 2.0, where organisations are expected to manage secure configuration as an ongoing practice rather than a one-time event.

Definitions vary across vendors on whether a baseline must be immutable, versioned, or tied to policy-as-code, but no single standard governs this yet. The most common misapplication is treating a baseline as a static inventory export, which occurs when teams fail to update the reference state after legitimate changes.

Examples and Use Cases

Implementing configuration baselines rigorously often introduces change-management overhead, requiring organisations to weigh operational speed against the ability to detect unsafe drift quickly.

• A service account baseline specifies that the account can only authenticate from a CI/CD runner, use a short-lived token, and write only to one storage bucket.
• A secrets baseline requires all API keys to live in a managed vault, which supports the findings in the Ultimate Guide to NHIs, where secrets sprawl and weak handling remain common.
• A Kubernetes baseline defines approved labels, admission rules, and workload identities so that newly deployed workloads can be checked against intended posture.
• A SaaS integration baseline records the expected OAuth scopes, callback URLs, and rotation cadence, then flags deviations after a change window closes.
• A Terraform or policy-as-code baseline captures the approved NHI permissions model and is validated against actual cloud IAM state before release.

In practice, baselines are most useful when paired with continuous verification and an audit trail. The concept also maps well to NIST Cybersecurity Framework 2.0 expectations for secure configuration and monitoring, especially where automation changes systems faster than humans can review them.

Why It Matters in NHI Security

Configuration baselines matter because NHI environments drift quietly. A token lifetime extended “just for testing,” a privilege added for an urgent release, or a vault path changed during troubleshooting can all remain invisible unless a known-good baseline exists. In NHI Management Group research, only 5.7% of organisations have full visibility into their service accounts, which makes baseline drift especially dangerous because teams often do not know what changed, when it changed, or which identity now has access. The Ultimate Guide to NHIs also shows that 97% of NHIs carry excessive privileges, underscoring how baseline failure can become privilege failure.

Without a baseline, incident responders cannot quickly tell whether a service account is behaving as designed or has been altered by an attacker, misconfiguration, or supply chain update. Baselines also support governance by defining what must be reviewed after deployment, rotation, or offboarding. Organisational teams typically encounter the cost of missing baselines only after an access review, outage, or compromise exposes that the “normal” state was never actually documented, at which point configuration baseline management becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do configuration checks miss identity risk in SaaS environments?
• What is the difference between SaaS configuration and SaaS governance?
• What is the difference between sensitive environment variables and ordinary configuration values?
• What breaks when hardcoded credentials are left in code or configuration files?