Context-rich certification

Expanded Definition

Context-rich certification is an access review model that asks certifiers to evaluate more than a name on a list. It surfaces signals such as recent usage, business role, approver history, privilege scope, and entitlement criticality so the reviewer can judge whether access is still justified. This matters because a reviewer cannot reliably approve or revoke what they cannot contextualise, especially when reviewing service accounts, API keys, or delegated agent access.

In NHI governance, the term sits between traditional access recertification and full privilege analytics. Traditional reviews often answer only “who has access,” while context-rich certification also helps answer “why is the access still present,” “how risky is it,” and “has it been used.” The model aligns closely with least privilege and ongoing verification principles reflected in NIST Cybersecurity Framework 2.0, but definitions vary across vendors on how much telemetry must be included before a review qualifies as context-rich.

For NHI programs, this usually means combining entitlement data with operational evidence from identity systems, CI/CD pipelines, or workload telemetry. NHI Management Group has shown how poor visibility amplifies risk in the Ultimate Guide to NHIs. The most common misapplication is treating a context-rich review as complete when the reviewer only sees role labels but not usage, owners, or privilege depth, which occurs when access governance tools are not integrated with actual identity activity.

Examples and Use Cases

Implementing context-rich certification rigorously often introduces review complexity, requiring organisations to weigh faster approvals against better risk decisions.

• A platform team reviews a CI/CD service account and sees it has not authenticated in 90 days, yet still holds production write access, so the certifier revokes it instead of rubber-stamping it.
• A security reviewer examines an API key tied to a deployment workflow and sees approver history, last use, and owner changes, enabling a decision based on evidence rather than title alone.
• An organisation applies the model to machine users after a pattern similar to the Sisense breach, focusing reviewers on dormant credentials and unusually broad entitlements.
• A business owner certifies an agent identity only after seeing the agent’s tool access, transaction scope, and recent executions, which helps distinguish legitimate automation from obsolete provisioning.
• An access governance workflow uses entitlement level plus ticket history to flag inherited permissions that no longer match the current project or service ownership.

Standards guidance is still evolving, so the exact data fields vary by platform. The important design choice is whether the reviewer gets enough evidence to answer risk questions without leaving the certification screen. That approach is consistent with the operational thinking encouraged by NIST Cybersecurity Framework 2.0 and with NHIMG guidance on reducing blind spots in identity governance.

Why It Matters in NHI Security

Context-rich certification matters because NHIs tend to accumulate privileges quietly, and review programs that lack evidence often preserve that sprawl instead of shrinking it. NHIMG reports that 89% of organisations face some form of NHI risk through overprivilege, weak rotation, or poor visibility, which means every ineffective review can leave exploitable access in place. When reviewers cannot see usage, ownership, or entitlement scope, they are more likely to approve stale access or miss a compromised identity entirely.

This becomes especially dangerous in environments with service accounts, API keys, and autonomous agents, where the access may be non-interactive and hard to notice after provisioning. Context-rich certification helps connect governance to real operational evidence, which is central to the identity resilience goals described in NIST Cybersecurity Framework 2.0. For NHI programs, the control value comes from forcing a human decision based on machine reality, not on spreadsheet residue.

Organisations typically encounter the need for context-rich certification only after a dormant account, leaked key, or overprivileged agent has already contributed to an incident, at which point the review process becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do context-rich AI workflows create new access risks?
• Context-Aware Certification
• Context-Rich Telemetry
• What is the Model Context Protocol (MCP) and why does it matter for security?