Unmanaged device controls reduce risk in BYOD and contractor access

At a glance

What this is: This is a customer story about using browser-based controls to differentiate managed and unmanaged device access for employees and contractors.

Why it matters: It matters because IAM and security teams need access policies that reflect device trust, especially where unmanaged endpoints intersect with contractor access, sensitive data, and remote access decisions.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Island's customer story on securing unmanaged devices and private access

Context

The core problem is that identity policy often assumes a stable, managed endpoint when many organisations now operate with contractors, BYOD devices, and mixed trust conditions. That gap becomes visible when access decisions need to account for both the user and the device state, especially for sensitive applications and data.

For IAM teams, this is a policy design issue as much as an access problem. When device posture and application access are separated, organisations tend to rely on brittle exceptions, inconsistent user experiences, or overbroad remote access paths. The identity angle is real here because the right access outcome depends on who is connecting, what device they are using, and whether that device can be trusted at that moment.

Key questions

Q: How should security teams handle unmanaged devices in access policy?

A: They should not treat unmanaged devices as equivalent to managed endpoints. The safer pattern is to apply conditional access, restrict sensitive workflows, and use browser-mediated controls or application-scoped remote access where possible. The goal is to preserve productivity while making device trust an explicit policy input instead of an assumption.

Q: Why do unmanaged devices complicate zero trust access decisions?

A: Because zero trust depends on continuous verification, and unmanaged devices weaken the confidence you can place in the session context. If the device cannot be assessed or controlled, identity alone is not enough to justify broad access. Teams need posture-aware policy, not just stronger authentication.

Q: What breaks when contractors use the same access path as employees?

A: Access policy becomes too coarse. Contractors often use personal or unmanaged devices, so identical treatment can lead to overexposure, more exceptions, or user workarounds that bypass governance. The practical fix is to define separate trust tiers and match access scope to the risk of the application and the device.

Q: How do organisations decide when browser-based access is appropriate?

A: Browser-based access is most useful when the organisation needs to reach web applications from devices it cannot fully manage but still wants to control the session. It is a good fit for contractor workflows, BYOD scenarios, and internal application access where the main goal is to reduce endpoint dependence without opening the network broadly.

Technical breakdown

How device posture assessment changes access decisions

Device posture assessment checks whether a device meets policy conditions before access is granted. In practice, this can include management status, browser state, security controls, or other signals that influence whether a session should be allowed, constrained, or redirected. The value is not in simply detecting unmanaged devices, but in making access decisions dynamic instead of binary. That matters in mixed-workforce environments because the same user may need different access paths depending on the device they are using and the sensitivity of the application they are opening.

Practical implication: define posture-based policy rules for unmanaged endpoints instead of using the same access path for every session.

Why browser-mediated access reduces endpoint dependence

Browser-mediated access shifts some controls away from the endpoint and into the session. That can reduce reliance on a fully managed device when an organisation still needs to enforce data handling boundaries, application segmentation, or conditional access. The architectural benefit is that users can access web applications through a controlled interface without exposing them directly to unmanaged local applications or unmanaged device contexts. This is especially useful where IT cannot mandate device enrolment for every worker or contractor, but still needs to preserve policy enforcement.

Practical implication: use browser-mediated controls to reduce direct dependency on unmanaged endpoints for sensitive application access.

Remote access to private applications without a traditional VPN

Private access tools create a controlled path to internal applications without requiring a full VPN client on every device. The security question is not whether remote access exists, but whether it is granted with application-level scope, identity checks, and policy enforcement that match the risk of the resource. That approach can be more granular than network-wide access, which is often too coarse for mixed trust environments. The design works best when internal application reachability is narrowed to specific users, sessions, and conditions rather than broad network exposure.

Practical implication: prefer application-scoped remote access for internal resources over broad network access paths where possible.

NHI Mgmt Group analysis

Device trust is now an identity problem, not only an endpoint problem. Once unmanaged devices can reach sensitive applications, access policy has to treat device state as part of the trust decision. That means IAM, conditional access, and session control need to work together rather than sit in separate silos. Practitioners should treat posture-aware access as a governance requirement, not a convenience feature.

Mixed managed and unmanaged access creates a policy bifurcation that many programmes still handle badly. If managed devices and unmanaged devices follow the same path, organisations either over-permit or force users into workarounds. The better model is distinct policy treatment with explicit risk boundaries, especially for contractors and temporary workers. Practitioners should expect access architecture to become more segmented as workforce diversity increases.

Browser-based enforcement helps close the gap between identity assurance and device assurance. This is one of the clearest intersections between identity governance and broader security architecture. The organisation still needs to know who the user is, but it also needs a safe way to express what that identity may do on a lower-trust device. Practitioners should align access policy with session context, not just authentication events.

Remote access tooling is becoming a control plane for sensitive collaboration, not just a connectivity layer. The practical shift is toward policy-driven access to internal apps, data, and collaboration tools from devices that cannot be fully managed. That has implications for auditability, data protection, and least privilege. Practitioners should re-evaluate whether legacy VPN assumptions still fit their workforce model.

What this signals

Posture-aware access will matter more as workforce boundaries blur. As contractors, BYOD users, and temporary collaborators become normal, access programmes need a more explicit trust model for devices that cannot be fully enrolled. The practical signal is that conditional access, browser enforcement, and session controls are moving closer to the centre of identity governance.

This is also a reminder that identity assurance and endpoint assurance cannot remain separate programme conversations. Where device trust is weak, organisations should expect more pressure on session-level controls, application segmentation, and policy exceptions. For practitioners, the next step is to review where unmanaged access is still handled through legacy VPN patterns.

Device trust gap: the risk arises when the organisation knows the user but cannot confidently govern the device they are using. That gap becomes visible in mixed environments, and it is where browser-based access, conditional policy, and lifecycle governance intersect most clearly.

For practitioners

• Define separate policies for managed and unmanaged devices Create explicit access rules that treat unmanaged devices differently from enrolled endpoints, especially for collaboration tools, internal applications, and sensitive data paths.
• Scope remote access to specific applications Replace broad network-level access with application-scoped controls so internal systems are reachable only through the minimum required path.
• Tie access decisions to device posture signals Use posture checks in conditional access so the session outcome changes based on device management state, browser context, and application sensitivity.
• Review contractor access separately from employee access Contractors often use less predictable devices and access patterns, so their workflows should be evaluated as a distinct policy class rather than folded into standard employee access.

Key takeaways

• Mixed managed and unmanaged device environments require access policies that adapt to device trust, not just user identity.
• Browser-mediated and application-scoped access can reduce dependence on unmanaged endpoints without broadening network exposure.
• Contractor and BYOD workflows should be governed as distinct trust categories, because uniform access rules tend to create exceptions or over-permissioning.

Key terms

• Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.
• Browser-mediated access: Browser-mediated access is access that is exercised through the browser rather than through a tightly controlled native client or backend workflow. It matters because many modern identity and data control failures occur after sign-in, during the live session where users interact with SaaS and AI tools.
• Application-Scoped Remote Access: Application-scoped remote access grants connectivity to specific internal applications rather than opening broad network access. This reduces blast radius, supports least privilege, and is better suited to mixed trust environments where users may connect from contractor or personal devices.

What's in the full article

Island's full post covers the operational detail this post intentionally leaves for the source:

• The exact policy flow used to redirect unmanaged-device users into the Enterprise Browser
• The private access configuration steps for reaching internal applications without a traditional VPN client
• The practical example showing how managed and unmanaged device experiences were separated
• The customer workflow details around deploying controls for a mixed employee and contractor environment

👉 Island's full post covers the policy setup, browser-based redirection, and private access configuration in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect identity policy, lifecycle controls, and access governance across modern environments.