Assigned Access

How Assigned Access Works

Assigned Access narrows a Windows sign-in to one approved experience, usually a single app or a limited shell. That makes it a configuration choice about what the local user can actually do after login, not a separate identity system or a replacement for device management.

In practice, the value comes from constraining the interactive surface. A kiosk user can often launch only the intended app, while access to the full desktop, settings, file system navigation, and unrelated tooling is removed or heavily limited.

Why Organisations Use It

Assigned Access is common where the device has a narrow purpose, such as public kiosks, shared front-desk terminals, check-in stations, or self-service endpoints. The goal is to reduce distraction, prevent tampering, and make the device less useful as a general-purpose workstation.

It is most effective when the business process itself is narrow. If a user only needs one workflow, forcing the device into that workflow can improve consistency and lower the chance that someone drifts into unsupported activity.

Security Boundaries And Limitations

Assigned Access changes the local user experience, but it does not by itself make the endpoint trustworthy. The device still needs normal hardening, patching, monitoring, and physical protection, because the configured app can still be abused if the endpoint is compromised or poorly maintained.

It also does not solve higher-level identity or authorization design. If the allowed app exposes sensitive data or administrative actions, that application must still enforce its own access control, session handling, and logging. A narrow shell is helpful, but it is only one boundary in the chain.

Kiosk and Shared Device Security Guide covers the broader controls that normally surround Windows kiosk-style deployments, including shared-device handling, session clearing, and monitoring.

Assigned Access In Windows Operations

For administrators, the practical question is whether the endpoint should behave like a managed kiosk or a flexible workstation. That decision affects enrollment, local account design, app selection, update cadence, and how quickly the device can be recovered if the kiosk app fails.

The strongest deployments treat Assigned Access as part of a broader endpoint operating model. The configuration should be reviewed whenever the app changes, the business process expands, or the device is repurposed, because a kiosk profile that once fit the job can become either too permissive or too brittle over time.

For control alignment, the same idea maps cleanly to access restriction and device-hardening practices in CIS Controls v8 and to the access-control and configuration families in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Related resources from NHI Mgmt Group

• What breaks when Oracle SoD reporting relies on assigned roles instead of effective access?
• Why do assigned roles in Oracle Cloud often overstate real access risk?
• What breaks when access is assigned through broad group-based provisioning?
• What breaks when IGA only tracks assigned access instead of reachable access?