Exclusion criteria

Expanded Definition

Exclusion criteria are the guardrails that tell a discovery or validation pipeline what not to classify as an application, workload, or managed SaaS asset. In NHI governance, that distinction matters because many pipelines are built to find identities, secrets, and access paths, but they can only be trusted when they also reject consumer sites, marketing properties, and other unmanaged domains that match superficial patterns.

Definitions vary across vendors, because some tools treat exclusion criteria as static allowlists while others support rule sets based on domain ownership, DNS patterns, tenant metadata, or network context. The practical goal is the same: prevent false positives before they enter reporting, remediation, or risk scoring. Used well, exclusion criteria sharpen inventory quality and reduce wasted investigation time; used poorly, they can hide real assets that deserve governance. That is why they should be reviewed alongside broader control logic such as the NIST Cybersecurity Framework 2.0 identification and asset management outcomes. The most common misapplication is excluding domains by keyword alone, which occurs when teams match on branding terms instead of verified ownership or operational context.

Examples and Use Cases

Implementing exclusion criteria rigorously often introduces a tradeoff: tighter filtering reduces noise, but it also requires more governance effort to avoid accidentally suppressing legitimate assets.

• A SaaS discovery process excludes public consumer portals so that only authenticated business tenants are evaluated for secrets exposure and NHI controls.
• A validation pipeline ignores parked domains and marketing microsites, because those properties may look similar to production applications but do not participate in identity workflows.
• A cloud inventory rule excludes test environments owned by a third party unless they are explicitly in scope for Ultimate Guide to NHIs style governance review, reducing false alerts during continuous scanning.
• A security team uses DNS suffix and certificate ownership checks to exclude internet-facing assets that are not managed by the enterprise, rather than relying on page content or logo similarity.
• A pipeline that maps machine identities to applications excludes known shared infrastructure endpoints, then routes them to separate review logic aligned to NIST Cybersecurity Framework 2.0 asset controls.

Why It Matters in NHI Security

Exclusion criteria are critical because NHI programs fail when discovery output is polluted with non-target assets. If unmanaged domains are mistaken for business applications, teams may overcount inventory, misallocate remediation work, or approve governance actions against the wrong owners. That weakens trust in the entire pipeline and can delay treatment of real service accounts, API keys, and automation identities.

NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, which means filtering logic often becomes the difference between actionable inventory and operational noise. Strong exclusion criteria support cleaner reporting, faster triage, and better alignment with governance standards, especially where discovery is used to drive risk reduction and Zero Trust planning. They also prevent teams from chasing phantom exposure on consumer-facing properties that never held privileged access in the first place. Organisations typically encounter the cost of weak exclusion criteria only after a remediation campaign stalls on false positives, at which point precise scoping becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Should organisations change procurement criteria for AI-native software?