A baseline configuration is the reference set of approved settings for a system, device, or application. It provides the starting point for compliance and drift checking, but it only remains useful when the organisation keeps validating it against current risk and operational context.
Expanded Definition
Baseline configuration is the approved reference state for a system, device, or application, used to compare current settings against expected controls and identify configuration drift. In NHI operations, that reference state must include service account settings, token handling, certificate parameters, API gateway rules, and automation defaults that affect how non-human identities authenticate and act.
Unlike a one-time hardening checklist, a useful baseline is a living control artifact. It should reflect current threat exposure, operational dependencies, and the identity posture defined in frameworks such as the NIST Cybersecurity Framework 2.0. Definitions vary across vendors when baselines are blended with policy templates, golden images, or compliance snapshots, but for NHI security the important distinction is whether the baseline can be measured and enforced continuously. The strongest baselines are versioned, approved, and tied to change control so that drift is visible, not merely documented.
The most common misapplication is treating a baseline as a static hardening document, which occurs when teams stop validating it after deployment and allow identity-related settings to drift unnoticed.
Examples and Use Cases
Implementing baseline configuration rigorously often introduces operational friction, requiring organisations to weigh tighter control and faster drift detection against the cost of more change approvals and exception handling.
- A platform team defines a baseline for service accounts that disables interactive login, restricts token scope, and requires rotation intervals aligned to policy.
- A CI/CD pipeline compares deployed container and secret-store settings against an approved baseline before release, blocking builds that reintroduce risky defaults.
- A security team uses the Ultimate Guide to NHIs as a reference for why baseline scope must cover credential storage, rotation, and visibility across the NHI lifecycle.
- An incident responder checks whether an API key, certificate, or workload identity has drifted from its baseline permissions after abnormal access is detected.
- An infrastructure team aligns the baseline for identity-related logging and alerting with the control expectations described in the NIST Cybersecurity Framework 2.0 so deviations are detectable.
Why It Matters in NHI Security
Baseline configuration matters because NHI environments fail quietly when defaults change, secrets are exposed, or privilege boundaries expand without review. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes baseline drift a practical security problem rather than an administrative one. When the baseline no longer matches the actual runtime state, teams lose the ability to distinguish sanctioned exceptions from unsafe misconfigurations.
This becomes especially important where policy is expected to support Zero Trust, privilege minimisation, and repeatable audit evidence. A baseline that is not current can create false confidence during reviews while leaving secrets, certificates, and automation credentials exposed. It also weakens incident response, because responders need a trusted reference point to decide whether a setting was intended or maliciously altered. Organisational failure usually becomes visible only after an outage, credential leak, or access event, at which point baseline configuration becomes operationally unavoidable to reconstruct what should have been running.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Baselines define approved NHI settings and help detect drift from secure defaults. |
| NIST CSF 2.0 | PR.IP-1 | Configuration baselines are a core part of established, maintained protection processes. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuously verified settings, not static trusted configurations. |
Version and enforce approved NHI baselines, then alert when runtime settings deviate.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
