TL;DR: Mixed personal and corporate device use has become the norm, with 35% of workers using their own devices and 66% using company-issued ones, according to JumpCloud. That shift pushes device management toward identity-centric controls, contextual policy, and Zero Trust assumptions that extend across endpoints, data, and access paths.
At a glance
What this is: This is a device-management explainer arguing that mixed-device workplaces require identity-centric access, Zero Trust, and contextual policies.
Why it matters: It matters because device diversity changes how IAM, NHI, and lifecycle controls enforce access, especially when users, shared endpoints, and third-party access all coexist.
By the numbers:
- Employees use their own devices (35%) alongside company-issued ones (66%), a far cry from the traditional one-to-one user-device model.
👉 Read JumpCloud's guide to managing access across mixed-device environments
Context
Modern device management is really an identity problem with a hardware layer attached. When employees move between personal phones, tablets, laptops, kiosks, and shared endpoints, the old one-user, one-device assumption stops holding, and access decisions have to follow identity, context, and device state instead of a fixed machine.
That shift affects human IAM directly, but it also shapes adjacent governance for shared workstations, third-party access, and other non-human endpoints that rely on tightly scoped access. The practical question is no longer whether a device is owned by the company, but whether the access path is continuously governed.
For teams that need a broader identity baseline, the underlying governance patterns are the same ones covered in the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide: visibility, lifecycle control, and access reduction when trust is not static.
Key questions
Q: How should security teams govern access across BYOD and company-owned devices?
A: Security teams should use identity-centric policy that evaluates device posture, user identity, and context at every access decision. BYOD and corporate devices should not share the same trust assumptions. Separate policies reduce the chance that an unmanaged endpoint inherits broad access simply because the user authenticated once.
Q: Why do mixed device environments weaken Zero Trust models?
A: Mixed device environments weaken Zero Trust when policy is written for a generic endpoint instead of the real mix of personal, shared, and managed devices. If device state is not continuously checked, access can outlive the endpoint conditions that justified it. Zero Trust depends on ongoing verification, not initial approval.
Q: What breaks when shared devices are governed like normal laptops?
A: Shared devices break normal laptop assumptions because multiple users, short sessions, and variable trust boundaries create a higher chance of residual access and data leakage. If shared endpoints are managed with the same controls as personal endpoints, lifecycle cleanup and session separation are usually too weak.
Q: Who is accountable when third-party or guest device access is over-extended?
A: Accountability sits with the team that owns access lifecycle and policy enforcement, not with the guest or vendor using the device. Third-party access must have explicit expiry, review, and revocation so delegated access does not become standing privilege. That is especially important where shared endpoints are involved.
Technical breakdown
Why mixed-device environments break static trust assumptions
A mixed-device environment combines managed, unmanaged, and shared endpoints, each with different patch levels, ownership models, and security posture. Static trust models fail because they assume the access context is stable, but device state changes constantly. The control problem is not just authentication. It is deciding whether a given session should continue to have access when the device, network, or user context shifts. Identity-centric device management turns the device into a policy input rather than the trust anchor.
Practical implication: base access on current context and device posture, not on the assumption that an enrolled device remains safe throughout the session.
How UEM and IAM have to work together
Unified Endpoint Management centralises enrolment, configuration, patching, and app deployment, but it does not replace IAM. IAM decides who or what should receive access, while UEM helps prove whether the endpoint is healthy enough to carry that access. In practice, the two controls are complementary. If UEM cannot feed reliable device state into access policy, access decisions become disconnected from actual risk. That gap is where personal devices, shared tech, and third-party endpoints create the most control drift.
Practical implication: integrate endpoint posture signals into access policy so enrolment, health, and authorisation are evaluated together.
Zero Trust for device sprawl
Zero Trust in this context means every access request must be re-evaluated against identity, device health, location, and risk. The model matters because device variety increases the chance that a single trust rule will be misapplied across very different endpoint types. Conditional access, continuous verification, and least privilege are the mechanisms that keep the environment from turning into broad, persistent access. Without those controls, device diversity becomes an exposure multiplier rather than a productivity enabler.
Practical implication: apply continuous verification and least privilege to every device class, including BYOD, shared devices, and third-party access.
Threat narrative
Attacker objective: The attacker aims to turn endpoint diversity and inconsistent trust enforcement into broader access to data and applications.
- Entry begins when users, contractors, or visitors connect through BYOD, shared tech, or third-party access paths that are not governed as tightly as corporate endpoints.
- Escalation occurs when inconsistent device visibility, weak conditional access, or fragmented policy lets the session retain more access than the endpoint should have had.
- Impact follows when data leakage, shadow IT, or compromised endpoints create exposure across apps and resources that were assumed to be safely segmented.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Device diversity is now an access governance problem, not just an endpoint problem. The article describes a workplace where personal, corporate, shared, and IoT devices all coexist, which means access control can no longer assume a uniform endpoint baseline. That changes the governance question from device ownership to trust continuity across the session. Practitioners should treat endpoint diversity as a core identity control issue.
Conditional access only works when device state is a real policy signal. If posture checks are superficial, IAM decisions are detached from the actual risk of the endpoint in front of the user. That creates a false sense of Zero Trust, because access appears governed while the device remains under-specified. The implication is that identity teams must demand better posture inputs, not just more policy statements.
Shared devices and third-party access expose the weakest lifecycle assumptions. Kiosks, POS terminals, flex desks, vendors, and temporary staff all depend on access that should expire cleanly and leave no residual privilege behind. When lifecycle offboarding is vague, access becomes reusable beyond the intended scope. Practitioners should assume every shared-access path needs lifecycle discipline, not just authentication.
Context-aware policy is the named concept this article sharpens. The underlying pattern is that access should change with user, device, time, location, and health rather than remaining fixed after initial authentication. That is the practical bridge between human IAM and broader endpoint governance. Teams that cannot express context in policy will keep compensating with manual exceptions and inconsistent enforcement.
From our research:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- For a broader identity baseline, the NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding need to stay aligned when access paths span users, devices, and service identities.
What this signals
Device sprawl is pushing identity teams toward a broader control model. As device types multiply, static trust is replaced by posture-aware access decisions, and that shift affects human IAM, shared endpoints, and adjacent non-human access paths. The programme signal is clear: access policy must become context-sensitive or drift will keep widening the enforcement gap.
Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security, and that confidence gap is a warning sign for endpoint governance too. The same control discipline that protects service identities also applies when devices become part of the trust chain. Organisations that cannot tie access to current context will struggle to govern BYOD, shared tech, and third-party access consistently.
Context-aware policy is becoming the practical bridge between endpoint management and access governance. The next maturity step is not more device inventory alone, but tighter integration between UEM telemetry, IAM enforcement, and lifecycle controls for temporary access. Teams that prepare now will be better positioned to handle flexible work without turning every new endpoint into a standing risk.
For practitioners
- Map access decisions to device posture inputs Feed device health, ownership, enrollment status, and compliance signals into conditional access so the policy engine can deny or step up access when the endpoint drifts from approved state.
- Separate corporate, BYOD, and shared-access policy paths Create distinct access rules for employee-owned devices, company-managed devices, kiosks, POS systems, and temporary access so one policy does not mask very different risk profiles.
- Tighten third-party and guest access lifecycles Require explicit expiry, review, and revocation steps for vendor, contractor, and guest access, especially where access is tied to shared devices or temporary workspaces.
- Connect UEM telemetry to IAM enforcement Use endpoint management data to inform authentication and authorisation decisions, rather than treating device management and access management as separate operational silos.
Key takeaways
- Mixed personal and corporate device use breaks the old one-device, one-user assumption and forces identity-first access governance.
- Zero Trust only remains credible when device posture, ownership, and session context are continuously checked and enforced.
- Shared devices, BYOD, and third-party access need separate lifecycle and policy controls or they will accumulate unmanaged privilege.
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-1 | Access control depends on device context and identity, which this article makes central. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous evaluation of device posture and session context. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle discipline matters where third-party and temporary access paths behave like non-human identities. |
Tie access decisions to verified identity and device state instead of assuming any endpoint is trustworthy.
Key terms
- Identity-centric access: An access model that makes identity, device posture, and context the basis for authorisation. Instead of trusting the endpoint by default, the policy engine evaluates whether the current session should be allowed, stepped up, or blocked based on live signals.
- Conditional access: A policy approach that grants or denies access based on defined conditions such as user identity, device health, location, or risk. In modern device management, it is the control that prevents authentication from becoming an unconditional gateway to corporate resources.
- Unified endpoint management: A management model that centralises enrolment, configuration, patching, and app deployment across multiple endpoint types. It improves consistency, but it still needs IAM integration to turn endpoint telemetry into actual access decisions.
- Zero Trust architecture: A security model that assumes no user or device is inherently trusted and requires continuous verification. In mixed-device environments, it means access must be re-evaluated as device state, location, and risk change rather than being granted once and left alone.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by JumpCloud: a blog on managing different types of devices in the modern workplace. Read the original.
Published by the NHIMG editorial team on 2025-06-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org