Shared devices and BYO mobile have different custody, recovery, and trust boundaries, so a single policy usually creates gaps. Personal devices cannot be treated like managed endpoints, and credential handling may differ by device class. When those patterns are collapsed, assurance becomes inconsistent and auditability weakens.
Why one access policy breaks down when device custody changes
Shared devices and BYO mobile are not just two form factors, they imply different custody models. A shared kiosk or pool device is usually controlled, reset between users, and operated under a managed trust boundary. A personal phone is privately owned, may persist user data and tokens, and is not always available for the same level of inspection, reset, or recovery after an incident.
That difference matters because access policy is not only about who can sign in, it is about what the endpoint is allowed to retain, how sessions are ended, and what evidence the organisation can rely on after use. When the same policy tries to cover both classes, it often treats the device as if it had the same lifecycle and recovery options, which it does not.
Credential handling is where the mismatch becomes most visible. On a managed shared device, short-lived sessions, enforced sign-out, and controlled local storage can be reasonable assumptions. On BYO mobile, the safer assumption is that device health, backup behaviour, and local persistence vary, so authentication strength alone does not guarantee the same assurance outcome.
What collapses first: trust boundary, session handling, and auditability
The first thing to break is usually the trust boundary. A shared device policy may assume the device is clean for the next user after logout or reset, but BYO mobile introduces a personal environment that the organisation does not fully own. That changes how you should think about cached credentials, app state, screenshots, push notifications, and recovery if the device is lost or replaced.
Session handling also diverges. Shared devices often need strict timeout, idle lock, and post-session wipe behaviour because multiple users can touch the same endpoint. Personal devices may instead need stronger device binding, conditional access, or app-level controls so the organisation does not overclaim control it cannot enforce. The policy breaks when it assumes one logout pattern works equally well for both.
Auditability is the third fault line. If the policy does not distinguish device class, the evidence trail can become hard to interpret: one class may support shared workstation style accountability, while the other produces user-owned device signals that are less deterministic. That weakens assurance reviews because investigators cannot tell whether a control failure is due to device reuse, personal configuration, or an exception that was never formally modeled.
How to separate controls without fragmenting the user experience
The practical fix is to separate policy intent from policy mechanics. The intent can stay consistent, such as requiring strong authentication, acceptable risk posture, and revocation on exit. The mechanics should differ by device class: shared devices need cleanup and reuse controls, while BYO mobile needs enrollment, app protection, and a more explicit stance on what can and cannot be stored locally.
A useful design rule is to align controls to custody, not just to the application. If the endpoint is shared, prioritise reset, non-persistence, and rapid re-assignment. If the endpoint is personal, prioritise bounded access, minimal data retention, and recovery steps that do not assume the organisation can wipe or repurpose the whole device. That is where mixed policies usually overreach.
For identity and access teams, authorisation models are useful only when they are paired with device-class rules, because the same role or entitlement can behave very differently on a managed shared endpoint versus a BYO phone. The access decision should reflect not just the user, but the trustworthiness and recoverability of the endpoint in front of them.
Risk and Threat Considerations
When shared and personal devices share one policy, the main risk is false equivalence: the organisation may believe it has the same control strength everywhere, when in reality persistence, data exposure, and recovery capability are materially different. That can leave tokens, cached sessions, or app data behind on a personal device, while also under-controlling reuse on a shared one.
Failure mechanism: The policy assumes one set of sign-in, sign-out, and storage rules can safely cover both custody models, so it neither wipes shared devices hard enough nor constrains BYO mobile tightly enough.
Impact: Assurance becomes uneven, incident recovery gets harder, and audit evidence stops proving what the organisation thinks it proves, especially after device loss, user turnover, or account compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Device class changes what access can safely be enforced after sign-in. |
| IA-5 — Authenticator Management | Mixed-device policy affects credential handling, reuse, and revocation. | |
| AU-2 — Event Logging | Mixed device classes weaken auditability unless events are logged consistently. | |
| Recommendation — Tie access decisions to endpoint trust and enforce different controls for shared and BYO devices. Set distinct credential handling and expiry rules for shared and personally owned devices. Log device class, session events, and recovery actions so investigations can distinguish custody models. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access policy must reflect different trust boundaries for shared and personal devices. |
| A.8.5 — Secure authentication | Authentication alone does not equal equal assurance across device classes. | |
| Recommendation — Document separate access rules for managed shared endpoints and BYO mobile. Require controls that account for device trust and persistence, not only sign-in strength. | ||
Practitioner Guidance
What to prioritise: Start by classifying device ownership and custody as a policy input, not an exception case. If you cannot describe what is retained locally, what can be wiped, and who controls recovery for each device class, the policy is too broad to be reliable.
What to verify: Check that the control set differs in at least three places, session lifetime, local persistence, and recovery action. A single policy statement is fine, but the enforcement path should not be identical when the endpoint is shared by many users versus personally owned.
Common mistake: Teams often over-index on login strength and under-specify post-authentication behaviour. The real failure usually appears after authentication, when a device keeps data or a session longer than the policy assumed.
Practitioner takeaway: Treat device class as part of the access decision itself. If the policy cannot absorb custody, reuse, and recovery differences, it is not one control framework, it is two different risk models pretending to be one.