Subscribe to the Non-Human & AI Identity Journal
Home Glossary Governance, Ownership & Risk Compliance baseline
Governance, Ownership & Risk

Compliance baseline

← Back to Glossary
By NHI Mgmt Group Updated June 23, 2026 Domain: Governance, Ownership & Risk

The minimum set of requirements an organisation must satisfy for a system, identity, or certificate to be considered trustworthy. In practice, the baseline should be measurable, current, and tied to operational evidence, not left as static policy text that no one tests against real change.

Expanded Definition

A compliance baseline is the minimum evidence-backed standard a system, identity, or certificate must meet before it can be treated as trusted in production. In NHI governance, that baseline usually covers provenance, ownership, expiration, rotation, storage location, privilege scope, and monitoring. It is narrower than full security maturity but broader than a checklist because it must be measurable and continuously verifiable.

Definitions vary across vendors, especially when teams blend compliance, security posture, and runtime policy into one control. NHI Management Group treats a baseline as the operational threshold that determines whether a non-human identity is allowed to keep operating, not merely whether a policy exists on paper. That distinction aligns with the NIST Cybersecurity Framework 2.0 emphasis on outcomes and governance evidence.

The most common misapplication is treating a baseline as a one-time onboarding approval, which occurs when teams never re-evaluate the identity after credentials, permissions, or hosting conditions change.

Examples and Use Cases

Implementing a compliance baseline rigorously often introduces review overhead, requiring organisations to weigh faster deployment against stronger control over identity risk.

  • A service account is only considered compliant if it has an owner, a documented purpose, no shared password, and a rotation interval enforced through policy, not manual reminders.
  • An API key may pass baseline checks only if it is stored in a secrets manager, has a scoped dependency, and is tied to evidence that it was issued for a specific workload.
  • A workload certificate can meet baseline requirements when its issuer, expiration, and revocation path are known and validated against current inventory, not stale records.
  • During audit preparation, teams map current NHI controls to the Ultimate Guide to NHIs — Regulatory and Audit Perspectives and use that record to show how the baseline is tested over time.
  • Security teams use the Top 10 NHI Issues to identify which baseline failures, such as leaked secrets or excessive privilege, are most likely to appear first.
  • Cloud architects compare baseline evidence with identity standards guidance in the NIST Cybersecurity Framework 2.0 when building control mapping for shared services.

Why It Matters in NHI Security

Compliance baselines matter because most NHI failures are not caused by a single missing control, but by drift. A workload may start compliant and later become unsafe as secrets are copied into code, ownership becomes unclear, or certificate rotation stops being enforced. When the baseline is ambiguous, security teams lose the ability to decide quickly whether an identity is trustworthy enough to keep running.

This is especially important in environments where NHIs outnumber human identities by 25x to 50x and where 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs. In that context, a weak baseline becomes a scaling problem, not just a policy defect. A single exception can replicate across pipelines, clusters, and third-party integrations. The operational lesson is that trust must be re-proven, not assumed.

Organisations typically encounter baseline failure only after a secret leak, an audit finding, or an incident response review exposes how long an unverified identity was allowed to operate, at which point compliance baseline management becomes operationally unavoidable to address.

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 CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.OVCompliance baselines depend on ongoing governance and evidence of control effectiveness.
NIST CSF 2.0PR.ACBaselines commonly include identity assurance, access scope, and permission validation.
OWASP Non-Human Identity Top 10NHI-02Secret handling and storage are core baseline checks for NHI trustworthiness.

Require each NHI to meet minimum access, ownership, and privilege criteria before production use.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org