When the device, not the account, has to carry the restriction
Kiosk mode configures a device to allow only a narrow, predetermined set of actions regardless of who's currently using it — a public terminal, a shared retail device, a lobby check-in screen. On a device like this, the device's own configuration becomes part of the access-control boundary: even a fully authenticated, legitimate user can't exceed what the kiosk permits, because the restriction isn't tied to a specific account or session at all.
This inverts an assumption most access-control design takes for granted — that the account, not the physical device, is the primary unit of authorization. A shared device intended for rotating or anonymous use may never have a stable notion of one persistent user to authenticate, which means the device's own configuration has to do work that would otherwise belong entirely to account-level permissions.
The specific risk of state left behind between users
A shared device carries a risk distinct from a personal one: state left behind by a previous session — a logged-in account, cached data, a half-completed action — becoming visible or usable by the next person to walk up to it. Kiosk configurations need an explicit, reliable reset between uses, not an assumption that whatever the previous session left behind is harmless simply because the device is meant for shared use.