Notifications
Clear all
Topic starter
12/07/2026 12:20 pm
TL;DR: Device identity becomes a prerequisite for zero trust when enterprises want to verify endpoints continuously, enforce policy by device state, and reduce reliance on static trust in managed and unmanaged environments, according to Cybertrust Japan. The governance gap is that device authenticity, lifecycle state, and certificate-based access must be treated as identity controls, not just endpoint hygiene.
NHIMG editorial — based on content published by Cybertrust Japan: Zero-trust architecture requires device management capabilities
By the numbers:
- CLOMO MDM reports a 97.6% retention rate.
Questions worth separating out
Q: How should security teams use device identity in zero trust access decisions?
A: Security teams should treat device identity as a live access signal, not a registration record.
Q: Why do managed devices still need continuous verification?
A: Managed devices can drift out of policy after enrollment through expired certificates, disabled controls, missing patches, or local tampering.
Q: What breaks when device certificates are deployed faster than lifecycle controls?
A: What breaks is the link between the credential and the device's approved state.
Practitioner guidance
- Map device trust signals to access policy Identify which decisions depend on enrollment status, certificate validity, OS version, lock state, and compliance posture, then tie those signals to conditional access rules.
- Make certificate lifecycle ownership explicit Assign clear ownership for issuance, renewal, revocation, and replacement so device certificates do not become unmanaged credentials after deployment.
- Use MDM data as an identity input Feed managed device posture into IAM and access control decisions instead of treating MDM as an administrative console separate from authorisation.
What's in the full article
Cybertrust Japan's full article covers the implementation detail this post intentionally leaves at the governance layer:
- How CLOMO MDM connects device certificate registration with endpoint distribution and remote management.
- The specific device security functions available in the platform, including restrictions, lock, wipe, and app control.
- The reasoning behind choosing certificate-linked device identity for mobile, Windows, and macOS endpoints.
- The vendor's own discussion of how zero trust changes endpoint operations in practice.
👉 Read Cybertrust Japan's analysis of device identity and zero-trust endpoint governance →
Device identity in zero trust: what controls are missing?
Explore further
12/07/2026 12:33 pm
Device identity is now a core zero-trust control, not an endpoint side note. When endpoints are part of the access decision, certificate state, enrollment state, and device posture become identity signals. That changes device governance from a support function into a control plane issue. Practitioners should treat device identity as a first-class input to IAM and PAM decisions.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should be accountable for device trust in a zero-trust programme?
A: Accountability should sit across IAM, endpoint management, and PKI ownership, with one clear control owner for the access decision. Zero trust fails when no team owns the full chain from device enrollment to revocation. The control objective is consistent proof of trust, not isolated tooling coverage.
👉 Read our full editorial: Zero trust device architecture needs stronger device identity
