1Password Device Trust external checks close the access-trust gap

At a glance

What this is: This is a product update showing that Device Trust can use external checks from other systems, not just device posture, to decide whether access should be allowed.

Why it matters: It matters because IAM and security teams often enforce policy in one system and control access in another, creating a gap that lets users reach sensitive apps before required conditions are met.

Context

The access-trust gap is simple to define: a control can know a user is on a compliant device, yet still miss whether the person has completed training, acknowledged policy changes, enrolled in MFA, or remains actively employed. In practice, that means enforcement and entitlement decisions are being made from partial evidence.

For IAM and NHI governance teams, the issue is not just device posture. It is whether access decisions can reflect conditions that live across HR, compliance, training, and security systems without creating another manual approval path. That is the governance problem this update addresses.

1Password positions Device Trust as a way to close that gap by pulling external signals into access decisions before sensitive applications are reached.

Key questions

Q: What breaks when device posture is not part of the access decision?

A: A valid user can still be granted access from a compromised or unmanaged device, which means identity assurance and device risk are being treated as separate problems. In practice, that leaves a gap between authentication and the actual trust state of the endpoint. Zero trust loses much of its value if device trust is invisible to the policy engine.

Q: Why do access controls need external compliance signals?

A: They need them because many access conditions live in HR, training, and security systems rather than on the device itself. Without those signals, organisations enforce compliance in one place and access in another, which leaves policy and entitlement disconnected at the moment it matters.

Q: How do teams know whether external checks are actually enforcing policy?

A: Look for a clear pass-or-fail dependency on an authoritative source of truth, consistent blocking when conditions are unmet, and remediation instructions that resolve the specific failure. If users can still reach protected apps while a required status is unresolved, the control is only advisory.

Q: What should security teams do when HR, compliance, and access policies are out of sync?

A: They should decide which system owns each access condition, then enforce that condition at the access layer instead of relying on manual review. That reduces drift between policy intent and real-world access, especially for joiners, movers, contractors, and leavers.

How it works in practice

External checks as a pass or fail access input

External checks work by letting Device Trust call a third-party system through an API at the moment of access. The external system acts as a source of truth for a requirement such as training completion, policy acknowledgment, MFA enrollment, or active employment status. It returns a simple pass or fail result, and Device Trust folds that result into the overall access decision alongside device posture. This is not full policy orchestration across systems. It is federated enforcement logic that keeps the access decision centralized while outsourcing verification of specific conditions to the right system of record.

Practical implication: treat the external system as an authoritative control point and define which requirements must be evaluated synchronously before access is granted.

Why device posture alone creates an enforcement blind spot

Device posture controls tell you whether the endpoint meets technical requirements, but they do not answer whether the user behind the device has satisfied organisational obligations. That gap matters when access is supposed to depend on both a trusted device and a trusted state for the person using it. Without external checks, teams end up enforcing compliance in one workflow and access in another, with no automatic link between them. The result is inconsistent enforcement, especially for contractors, onboarding gates, and policy acknowledgments that can change faster than device health.

Practical implication: map every access condition that lives outside endpoint management and decide whether it belongs in access-time enforcement instead of after-the-fact review.

Zero Trust needs identity and compliance signals, not only endpoint signals

Zero Trust is often described as verifying the right user, on the right device, under the right conditions, for the right application. External checks make that model more practical because they let access decisions reflect organisational signals that were previously disconnected from the access path. The mechanism is especially relevant where identity governance spans human IAM and non-human access workflows, because standing assumptions about trust can fail when the source of truth lives in another system. The central issue is not just telemetry quality. It is whether your access layer can consume the business conditions that govern entitlement in real time.

Practical implication: align access policy with the specific identity and compliance signals that define trust in your programme, rather than relying on device telemetry as a proxy.

NHI Mgmt Group analysis

Access enforcement fails when compliance and access decisions live in separate systems: This update exposes a common governance flaw, not a feature gap. Organisations may already have the policy, the training requirement, and the HR status signal, but still lack a runtime link between those systems and the access decision. The implication is that enforcement architecture, not policy intent, is what determines whether controls actually work.

Cross-system trust checks are now part of identity governance, not an endpoint add-on: The article shows that access conditions increasingly depend on business-state signals such as employment status and policy acknowledgment, not just machine health. That moves the control problem into the identity layer, where access governance, lifecycle state, and compliance evidence have to line up. Practitioners should treat these checks as a governance pattern, not a device-management tweak.

Access-trust gap: a useful named concept for the control split this article describes: The gap appears when systems that collect compliance evidence are disconnected from systems that enforce access. That creates a state where an organisation can prove noncompliance in one place while still granting access elsewhere. The practitioner implication is that trust needs to be enforced at the moment of access, using the authoritative signal for each condition.

This pattern strengthens Zero Trust only if the external signal is truly authoritative: Pulling in more signals does not automatically improve assurance. If the external source is stale, inconsistently updated, or weakly governed, the access decision simply becomes more complex without becoming more trustworthy. The operational question is whether each external check is tied to a system that ownership, update cadence, and remediation workflows can support.

For mixed human and machine identity programmes, the lesson is lifecycle alignment: The update is about humans, but the underlying governance principle generalises. Access should reflect current lifecycle state, whether the subject is an employee, contractor, service account, or AI agent. Teams that already manage non-human identity state should recognise the same pattern here: entitlement is only defensible when the source of truth and the enforcement point move together.

What this signals

Access-trust gap: The practical problem is not missing policy, it is the lack of enforcement linkage between policy systems and access systems. When compliance evidence sits in one place and entitlement decisions sit in another, organisations create a gap that Zero Trust is supposed to remove. The control has to evaluate business state at the moment access is requested.

For teams governing human identity, this pattern is a reminder that lifecycle state and compliance state are part of access control, not separate administrative chores. For teams managing NHI or agentic workflows, the same lesson applies in different form: the access decision must be anchored to the current source of truth, not to stale assumptions about who or what is still entitled.

Device posture remains necessary, but it is no longer sufficient on its own. The next phase of identity governance is not adding more approvals, but connecting the approval source, the compliance source, and the access enforcement point so they operate as one control surface.

For practitioners

• Define which external conditions are access blockers List the signals that must be checked at access time, such as training completion, policy acknowledgment, MFA enrollment, or employment status, and classify each as hard stop or advisory only.
• Map each signal to a system of record Assign one authoritative source for every external check so Device Trust is not making decisions from duplicate or conflicting records across HR, compliance, and security tools.
• Test failure paths before rollout Validate what happens when the external system is unavailable, returns stale data, or reports a fail condition so access policy and user remediation instructions behave predictably.
• Align external checks with lifecycle events Connect access enforcement to joiner, mover, and leaver changes so employment status and policy acknowledgments are reflected before users retain access they should lose.
• Audit the trust chain for contractor access Review contractor onboarding and offboarding paths to confirm that access depends on live compliance state, not only device posture or a one-time approval.

Key takeaways

• The article describes a real governance gap: organisations can hold the right policies and still grant access because enforcement and compliance signals are disconnected.
• External checks make access decisions depend on organisational state such as training, policy acknowledgment, MFA enrollment, and employment status, not just device posture.
• The practical change for IAM teams is to treat access-time verification as a cross-system control problem and align the source of truth with the enforcement point.

Key terms

• External check: A control pattern where an access system asks another system to confirm a requirement before allowing access. The external system returns a pass or fail result, turning a separate governance signal into part of the access decision itself.
• Access-trust gap: The gap between having a policy and actually enforcing it when access is requested. It appears when compliance, HR, or training data sits in separate systems from the access decision, allowing users to reach resources even though a required condition has not been met.
• Source of truth: A source of truth is the authoritative store that holds the current, trusted version of project state or operational knowledge. For AI workflows, it should be a controlled system such as a repository, task platform, or note vault that agents can read and update through governed access paths.
• Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.