A linked device is an approved secondary endpoint that inherits access to a user’s account and messages. It is a high-value trust boundary because once approved, it can extend access without re-entering primary credentials, making enrolment and revocation critical controls.
Expanded Definition
A linked device is an approved secondary endpoint that inherits access to a user account and its messages after an initial trust decision. In practice, that means the device can receive session continuity, notifications, or message visibility without re-presenting the primary user’s credentials each time. The security meaning is narrower than generic “trusted device” language: the device is not trusted because it is convenient, but because an identity system or application has recorded an explicit enrolment event and a policy path for continued access.
Definitions vary across vendors, especially in messaging, collaboration, and consumer identity products, but the core control concern is consistent: a linked device creates a persistent trust boundary that must be enforced through enrolment, posture checks, and revocation. This is closely aligned with zero trust principles described in the NIST Cybersecurity Framework 2.0, because access should remain conditional rather than permanently implied by a prior approval. The most common misapplication is treating link approval as a one-time convenience step, which occurs when organisations fail to define device expiry, revalidation, or loss-response procedures.
Examples and Use Cases
Implementing linked devices rigorously often introduces more enrolment friction and more lifecycle work, requiring organisations to weigh user continuity against the cost of stronger revocation and monitoring.
- A collaboration app lets a laptop mirror messages from a phone after QR-based enrolment, then blocks the laptop if the device health check fails.
- An enterprise messaging system allows a tablet to remain linked for field work, but requires re-approval after a policy-defined period or OS upgrade.
- A help desk workflow removes a linked device from an account immediately after a reported theft, preventing continued message access from a lost endpoint.
- A security team reviews linked devices alongside NHI posture data because persistent endpoints can behave like long-lived access carriers, similar to the risk patterns documented in the Ultimate Guide to NHIs.
- A zero trust deployment uses conditional access and device attestation so the linked device remains usable only while it satisfies current policy, consistent with NIST Cybersecurity Framework 2.0 guidance on continuous risk management.
Why It Matters in NHI Security
Linked devices matter because they extend a user’s trust envelope beyond the original authentication event. That extension becomes especially dangerous when enrolment is weak, revocation is slow, or device inventory is incomplete. A linked device can function as a durable access path even after the primary phone is replaced, the employee leaves, or the endpoint is stolen. In NHI-adjacent environments, the same governance pattern appears when systems allow secondary endpoints or companion clients to inherit access without clear lifecycle ownership.
NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them consistently. While that statistic refers to NHIs rather than mobile endpoints, the operational lesson is the same: long-lived inherited access is hard to unwind once it exists, especially when visibility is poor. This is why linked device governance should include asset inventory, time-bound enrolment, step-up revalidation, and immediate revocation paths. Organisational exposure often becomes visible only after a lost device, account takeover, or unexplained message access, at which point linked-device control turns from a convenience feature into an incident response requirement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Linked devices depend on controlled, continuously reviewed access decisions. |
| NIST Zero Trust (SP 800-207) | Zero trust requires each linked device to remain conditionally trusted, not permanently implied. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Inherited access and revocation gaps mirror the control focus on lifecycle and secret governance. |
Limit linked-device access to approved conditions and revoke it promptly when trust changes.
