User Criteria

How User Criteria Work

User criteria sit at the decision point between a request and a policy outcome. They are the rules a system evaluates to determine whether someone can proceed, and they typically combine multiple signals rather than a single yes-or-no check. That makes them more expressive than a basic allowlist because they can reflect context, assurance, and operating conditions at the moment of access.

In practice, user criteria often blend identity attributes with environmental conditions. A role may be acceptable, but only if the device is managed, the network location is expected, or the session meets a required assurance level. The key idea is that the system is not just asking who the person is, but whether the present context is sufficient for the requested action.

Where User Criteria Appear

User criteria are common in conditional access, enrollment flows, and just-in-time access decisions. They can also appear in provisioning logic, where the system decides whether to create an account, assign entitlements, or require extra verification before granting a stronger privilege level.

Because these criteria are often assembled from several sources, they are only as reliable as the inputs behind them. If group membership is stale, device posture is misreported, or location signals are weak, the decision can be too permissive or too restrictive. That makes user criteria a control-plane concept as much as a policy concept.

Why User Criteria Matter

User criteria help organisations express policy in a way that matches real-world trust decisions. They are especially useful when access should depend on context that changes over time, such as whether the device is healthy, whether the user has recently satisfied a stronger authenticator, or whether the request originates from an approved environment.

They also reduce the need to hard-code access decisions into individual applications. Instead of each app inventing its own rules, a shared decision layer can apply consistent criteria across authentication, enrolment, and access granting. That consistency matters when the goal is to align user experience with security posture rather than treat them as separate problems.

Common Implementation Pitfalls

User criteria become brittle when organisations treat them as static labels instead of living policy inputs. Role and group data drift, device trust can decay, and location-based checks can be noisy. If the criteria are too broad, they silently permit access that should have been challenged; if they are too strict, they create avoidable friction and workarounds.

Another frequent issue is confusing the criterion itself with the source of truth behind it. A “managed device” condition is only useful if device inventory, compliance state, and policy enforcement are dependable. A “high assurance” requirement is only meaningful if the underlying authentication signal is measurable and consistent.

Risk and Threat Considerations

User criteria create security exposure when defenders trust weak or stale signals to make access decisions. An attacker who can satisfy the visible rule set, or manipulate one of the inputs, may be able to reach enrolment, authenticate successfully, or obtain access that should have been blocked or stepped up.

Failure mechanism: A policy engine accepts incomplete, outdated, or spoofable context, so the access decision no longer matches the real risk of the session or requester.

Impact: Excessive access, fraudulent enrolment, account takeover paths, and inconsistent enforcement across systems can follow, especially when the same criteria are reused broadly.

Practitioner Guidance

Governance implication: Treat user criteria as policy assets that need ownership, review, and change control. The most important question is not whether a criterion sounds sensible, but whether its input data, evaluation logic, and fallback behaviour are trustworthy enough for the access it governs.

Practitioner takeaway: Use user criteria to express risk-based decisions, but verify the quality of every signal they depend on, because brittle inputs turn a good policy into a false sense of control.

Related resources from NHI Mgmt Group

• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern infrastructure identities alongside user identities?
• What is the difference between managing user accounts and managing NHIs?
• What is the difference between service account risk and user account risk in AD?