Teams should test the directory query logic against the underlying wildcard behavior, not just the portal label. In this case, a Not Starts With condition using the percent sign can identify records where an attribute is empty. The practical lesson is to validate set membership against real data, then confirm the query still behaves correctly as provisioning quality changes.
Why directory-set logic can disagree with what the portal label suggests
A criteria-based set is only as reliable as the query semantics behind it. When an attribute is blank, a UI label like “starts with” may not tell you how the backend treats null, empty string, or wildcard matching. That is why the useful test is the actual directory filter behavior, not the human-readable label alone.
In practice, this kind of check belongs to identity and access administration because set membership often drives provisioning, exclusion, or review scope. If the query misclassifies blank values, the result can be silent drift between the intended population and the accounts or records actually included.
One practical way to reason about the set is to treat blank or missing values as a data-state problem first, then as a filtering problem second. A query that appears simple in the portal may rely on wildcard semantics that behave differently for empty values, so the same rule can produce different membership outcomes depending on how the directory stores absence.
What to test when an attribute may be empty or inconsistently populated
Start with known records that cover the edge cases: populated values, empty strings, nulls, whitespace-only values, and records where the attribute is absent altogether. Then compare what the set returns with what you expect from each state, because the important question is whether the rule matches the underlying data model, not whether it looks correct in the builder.
If the set depends on wildcard logic, validate the exact operator behavior against real records before trusting it for production use. A pattern such as Not Starts With with a percent sign may be able to capture empty entries, but teams should confirm the platform’s interpretation of that expression instead of assuming that all blank states are handled the same way.
That same testing discipline is especially important when provisioning quality changes over time. A set that works today can become inaccurate if upstream data entry improves, an attribute changes from optional to required, or a synchronization process starts populating values more consistently.
Why the query should be rechecked as data quality improves
Criteria-based sets are often used as control inputs, so a query that once caught empty attributes may later become too broad or too narrow. As data quality changes, the rule may start including records that are no longer blank, or it may miss edge cases introduced by a new source system or directory sync pattern.
This is why teams should not treat set validation as a one-time setup task. The set definition, the source data profile, and the provisioning workflow should be reviewed together whenever the attribute’s population pattern changes, especially if the set is used for access assignment, exclusion logic, or lifecycle automation.
In a directory context, the main failure mode is quiet misalignment rather than an obvious error. The query can still execute, the portal can still display the set, and only a comparison against live records reveals that the underlying membership logic no longer reflects the intended population.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Directory-set logic affects account and attribute-driven access workflows. |
| Recommendation — Validate attribute-driven membership rules before they influence account or access changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question concerns control logic that determines which records are included in access-related sets. |
| Recommendation — Test set logic against live data before using it for access decisions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Criteria-based sets can determine who is included in access-related administration and review. |
| Recommendation — Verify that directory rules match intended access populations before deployment. | ||
| CIS Controls v8 | CIS-5 — Account Management | Blank-attribute set logic can affect which accounts are included in operational account management. |
| Recommendation — Review account-selection logic against actual directory values and edge cases. | ||
Practitioner Guidance
What to verify: Test the set against representative records, including null, empty, whitespace-only, and populated values, before relying on it for operational decisions. Confirm whether the platform treats missing values differently from empty strings, because that distinction often determines whether the filter is trustworthy.
Decision rule: If the set will drive provisioning, review, or exclusion, validate it against live data and re-run the check after any upstream schema or sync change. If the attribute is becoming better populated over time, re-evaluate whether the blank-value rule still belongs in the set or should be replaced with a more explicit condition.
Practitioner takeaway: Treat the portal label as a hint, not proof, and trust the set only after the query has been proven against real directory states.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- How should security teams use Active Directory attributes to move from group-based access to attribute-based access control?
- How should security teams implement attribute-based access control in a legacy directory environment without creating more administrative overhead?
- How should security teams prioritise NHI remediation in cloud environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
