Notifications
Clear all
Topic starter
10/06/2026 11:21 pm
TL;DR: Access enforcement can now reflect cross-system conditions, not just device posture, as Device Trust can use external compliance signals such as training completion, policy acknowledgments, MFA enrollment, and employment status before granting access, according to 1Password. The practical shift is that access enforcement can now reflect cross-system conditions, not just device posture.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full announcement
1Password's full research covers the operational detail this post intentionally leaves for the source:
- The exact Device Trust configuration model for creating and managing External Checks across systems.
- The policy and remediation workflow examples for blocked users, including how custom instructions are presented.
- The specific third-party signal types that can be used as pass or fail inputs in access decisions.
- The product documentation path for connecting Device Trust to an external API source of truth.
👉 Read 1Password's analysis of External Checks in Device Trust →
Device Trust external checks: are your access controls keeping up?
Explore further
12/06/2026 5:15 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: 1Password Device Trust external checks close the access-trust gap
