How do teams know whether certification campaigns are too broad?

A certification campaign is too broad when reviewers are asked to assess too many entries without enough risk context. Look for risk-based scoping, meaningful segmentation, and evidence that reviewer decisions reduce workload while preserving auditability, rather than simply speeding up the same review volume.

Why This Matters for Security Teams

Certification campaigns are supposed to confirm who still needs access, who no longer does, and whether exceptions are justified. When the scope is too broad, reviewers end up approving large batches with weak context, which turns a control into a checkbox exercise. NIST’s NIST Cybersecurity Framework 2.0 emphasizes repeatable governance outcomes, not volume for its own sake, and that distinction matters here.

For NHI-heavy environments, the same problem appears in a different form: teams try to review every secret, token, service account, or machine credential as if they were all equally risky. NHIMG research on The State of Secrets in AppSec shows how fragmentation and weak hygiene already make secrets governance noisy. If the campaign does not segment by system criticality, privilege level, or ownership, reviewers cannot distinguish high-risk entitlements from low-value clutter.

In practice, many security teams discover a campaign was too broad only after approvers have mechanically clicked through hundreds of entries with little actual decision-making.

How It Works in Practice

The fastest way to test campaign breadth is to ask whether each review item has enough context to support a real decision. Good scoping groups access by business function, application tier, privilege level, environment, or NHI type rather than dumping everything into one list. For non-human identities, that usually means separating human accounts from workloads, and separating routine machine secrets from privileged or externally reachable credentials.

Teams should expect the campaign design to reduce review volume through segmentation, not merely through a faster user interface. A useful campaign gives reviewers the signal needed to answer: does this identity still need this access, is the access still proportionate, and is there evidence of recent use or operational dependency? That is consistent with the direction of NIST CSF governance outcomes and with the identity-centric framing in Ultimate Guide to NHIs — What are Non-Human Identities.

• Segment by risk, owner, and system criticality before opening the campaign.
• Include last-used data, privilege tier, and exception history for each entry.
• Exclude dormant, duplicate, or already-remediated items from the active review set.
• Track reviewer override rates and closure quality, not just completion speed.

For broader governance alignment, current guidance suggests pairing campaign design with access recertification evidence, ownership validation, and documented remediation paths. That makes the review auditable without forcing every reviewer to inspect irrelevant entitlements. NHIMG’s Sisense breach coverage is a useful reminder that overexposed credentials and unclear ownership create conditions where access reviews become too large to be meaningful. These controls tend to break down when inventories are incomplete, because reviewers cannot trust the scoping data enough to make narrow decisions.

Common Variations and Edge Cases

Tighter scoping often increases preparation effort, requiring organisations to balance review precision against data quality, inventory maturity, and operational overhead. That tradeoff is unavoidable when a campaign spans many systems, especially in hybrid estates where one team may own dozens of service accounts, APIs, and third-party integrations.

Best practice is evolving for agentic and automated environments, where there is no universal standard for whether every workload identity should be recertified on the same cadence as human access. In some cases, a workload registry with runtime attestations is more useful than a traditional attestation form, particularly when identities rotate quickly or are created per task. The DeepSeek breach is a cautionary example of why broad, unsorted inventories create review noise and hide the truly sensitive items.

Campaigns are probably too broad when one reviewer owns too many unrelated systems, when exception rates are high because the list is poorly curated, or when almost every decision requires escalation. That usually means the team has not built a risk model strong enough to separate routine access from privileged or exposure-prone access. In that situation, the remedy is narrower scoping, not more reviewer effort.

Related resources from NHI Mgmt Group

• How do security teams know whether secrets access is too broad?
• How do security teams know whether management-plane access is too broad?
• How do security teams know whether investigation access is too broad?
• How do security teams know whether AML identity scope is too broad?