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

At a glance

What this is: 1Password Device Trust now accepts External Checks so access decisions can factor in off-device compliance and employment signals, not just device posture.

Why it matters: That matters because IAM teams can no longer rely on device-only checks to enforce policy when human identity, compliance, and access systems are decoupled.

👉 Read 1Password's analysis of External Checks in Device Trust

Context

Device trust is strongest when it evaluates more than the endpoint. In many enterprises, the access decision still ignores whether a user has completed training, acknowledged a policy, or remained active in HR systems, which creates an access-trust gap between governance systems and enforcement systems.

For human identity programmes, that gap matters because compliance obligations often live in one system while access control lives in another. If those signals are not connected, organisations can meet policy on paper while still granting access in practice.

Key questions

Q: How should security teams enforce compliance conditions at access time?

A: Security teams should connect the compliance source of truth directly to the access decision so policy is enforced when the user requests access, not after the fact. That means deciding which conditions are hard gates, defining how the system responds to missing or stale signals, and limiting the control to the applications where enforcement matters most.

Q: Why do device-only controls leave an access-trust gap?

A: Device-only controls prove something about the endpoint, but not necessarily about the user’s compliance state, employment status, or policy acknowledgments. When those human identity signals stay in separate systems, access can be granted even though the organisation has not actually enforced its own requirements.

Q: What breaks when compliance and access systems are not connected?

A: The organisation ends up with policies that exist for audit purposes but do not affect real-time access. That creates a gap between governance and enforcement, especially for sensitive applications where a missed training step or failed acknowledgment should have blocked access.

Q: Who should own external verification signals in IAM governance?

A: Identity and access teams should own the access decision, even when the signal comes from HR, training, or compliance systems. Ownership matters because the control only works when someone defines which signals matter, how fresh they must be, and what happens when a check fails.

How it works in practice

External checks in device trust

External Checks extend device trust by letting an access policy call out to another system through an API before access is granted. The external system acts as a source of truth for a specific condition, such as policy acknowledgement or employment status, and returns a simple pass or fail response. Device posture remains part of the decision, but it is no longer the only input. This changes device trust from a local posture check into a broader enforcement point that can reflect enterprise governance data already held elsewhere.

Practical implication: connect the specific governance signal that matters to the application, not every available signal.

Cross-system enforcement and access decisions

The architectural change here is not the policy itself, but the decision path. A request now moves from device evaluation to an external verification step and then back into the access engine for a final allow or block decision. That introduces a more complete trust model, but also a dependency on API reliability, signal quality, and clear remediation logic. If the external source of truth is stale or ambiguous, the access decision becomes only as trustworthy as the weakest upstream record.

Practical implication: treat each external signal as an access control dependency that needs ownership, freshness, and failure handling.

Zero Trust and the access-trust gap

Zero Trust depends on verifying the right user, device, and conditions before access is granted. When compliance systems and access systems operate separately, organisations create an access-trust gap: the policy exists, but enforcement is incomplete. External Checks are an attempt to close that gap by pulling human identity and governance signals into the access decision itself. The technical point is simple: trust is only useful if it is evaluated at the moment access is requested, not only at policy design time.

Practical implication: map which compliance conditions must be evaluated at request time rather than reviewed after the fact.

NHI Mgmt Group analysis

Access-trust gap: This change addresses a familiar identity governance failure where policy exists in one system and enforcement lives in another. The gap is not lack of rules, but lack of decision-time connection between compliance state and access control. In practice, organisations have treated acknowledgments, training, and employment status as governance facts, not enforcement inputs. Practitioners should now treat those facts as access conditions, not just audit evidence.

Device posture alone is an incomplete trust model for human access. Device health matters, but it does not prove that the person behind the device has met organisational obligations. When the access decision ignores compliance state, the organisation can grant access to a trusted endpoint with an untrusted user context. That is a governance gap, not just a technical blind spot. Practitioners should re-evaluate which human identity signals must be enforced at access time.

Zero Trust for human identity is increasingly a cross-system control problem. The article shows that the access path now depends on HR, training, security, and identity systems working together. That means identity teams must own the trust boundary even when the signal originates elsewhere. The implication is that access governance is no longer an IAM-only problem or a device-only problem. Practitioners should design for orchestration across systems, not isolated control points.

Compliance signals become operational controls only when they are machine-readable and decisioned in real time. A policy acknowledgment or active employment status has limited value if it is reviewed manually or exported into a spreadsheet. The new model points toward event-driven enforcement, where governance data is consumed at the point of access. Practitioners should assess which controls can be converted into live enforcement signals without creating brittle dependencies.

1Password Device Trust is a symptom of a wider market shift toward decision-layer identity controls. Identity security is moving away from static verification and toward access decisions that incorporate context from multiple systems. For practitioners, that means mature programmes will increasingly need policy orchestration across compliance, HR, and device signals. The governance question is no longer whether a requirement exists, but whether it can be enforced when access is requested.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• Averaging 27 days to remediate a leaked secret, organisations often discover that policy exists long before enforcement catches up, according to The State of Secrets in AppSec.
• That governance lag is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is relevant when access conditions depend on lifecycle state.

What this signals

Access governance is moving toward decision-time enforcement. If compliance signals cannot be evaluated at the moment access is requested, they remain documentation rather than control. Teams that run human identity, device trust, and compliance in separate tracks will need to decide which conditions are worth turning into live gates and which can remain audit evidence.

Compliance signals only matter when they are operationalised. Acknowledgments, training completion, and employment state need ownership, freshness rules, and clear failure behaviour. For programmes already using Zero Trust language, the practical test is whether the control actually blocks access or merely records intent.

The broader signal is that identity programmes are becoming orchestration problems across HR, security, and access tooling. That is where the Ultimate Guide to NHIs , Regulatory and Audit Perspectives becomes useful, because governance questions increasingly depend on proving that policy was enforced, not just defined.

For practitioners

• Map every access condition to its source of truth Identify which requirements live in HR, training, compliance, or security systems and decide which of them must block access at request time. Prioritise conditions that affect sensitive apps and data.
• Define failure handling for external checks Set explicit policy for what happens when an external system is unavailable, returns stale data, or cannot answer cleanly. Avoid silent allow paths that weaken the control when integrations degrade.
• Limit external checks to high-value enforcement points Start with the applications where a missed policy acknowledgment or inactive employment status would create the greatest exposure. Do not spread cross-system checks across low-risk resources before the process is stable.
• Align remediation instructions to the failed control Use user-facing guidance that tells the person exactly which system or requirement needs attention, such as completing training or refreshing an HR status. Keep remediation tied to the signal that failed.

Key takeaways

• Device trust becomes materially stronger when it can consume external compliance and employment signals at access time.
• The core risk is an access-trust gap, where policies exist but do not influence real-time enforcement.
• Practitioners should map which human identity conditions are hard gates, then make their failure behaviour explicit.

Key terms

• 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.
• 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.
• Source of truth: The authoritative system for a specific identity or compliance fact, such as employment status, training completion, or policy acknowledgment. In practice, access controls become stronger when they query the correct source of truth at the moment a decision is made.

Deepen your knowledge

Device trust, compliance enforcement, and cross-system access signals are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance controls that must span human identity and device posture, it is worth exploring.

This post draws on content published by 1Password: Device Trust external checks and the access-trust gap. Read the original.