Choose Windows Kiosk and Auto-Login Options for AV

Choose automatic sign-in only when the venue accepts its physical access implications, and choose kiosk controls according to the Windows edition and application type. Automatic sign-in is not a lockdown mechanism. A desktop AV application that needs a user session must be tested in that session, including maintenance access and recovery after updates.

Separate three requirements

First decide whether the PC must sign in unattended, whether visitors must be restricted to an application, and whether maintainers need a separate desktop. These are different requirements. A startup shortcut can open a control interface without preventing access to Windows, while a restricted kiosk experience may not support the intended desktop application in its simplest mode.

Microsoft's Assigned Access overview lists supported editions, including Pro, Enterprise, Education and IoT Enterprise variants. Home is not on that list. Its single application kiosk and restricted user experience are distinct configurations; confirm current application and build requirements before selecting one.

Check the edition before designing around a feature

Shell Launcher supports Enterprise, Education and IoT Enterprise editions, including the listed LTSC variants; it is not a Pro or Home feature. It replaces the shell after sign-in but does not by itself prevent access to other system components. Do not sell a Pro based design that silently depends on Shell Launcher.

Record the actual Windows edition, build, licensing arrangement and application packaging. A Flutter desktop application should not be assumed to work in the same kiosk configuration as Microsoft Edge or a UWP application. Test the intended supported deployment rather than using registry shell edits as an undocumented substitute.

Evaluate automatic sign-in explicitly

Microsoft's Sysinternals Autologon documentation explains that privileged administrators can recover its stored secret. Use a dedicated least privilege operator account and keep domain administrative credentials out of kiosk sign-in. Have the venue owner approve the physical access implications and define how account rotation affects unattended startup.

Do not include passwords in a commissioning screenshot, exported script or public handover document. Store recovery credentials through the venue's approved secret management method and test that an authorized maintainer can reach the separate maintenance account.

Qualify boot and maintenance paths

Include a failed sign-in exercise on the bench: make the test credential unavailable through the approved account process and observe the screen presented to staff. Document the recovery route without storing the password in the public operator instructions. Restore the test account before returning the machine to service.

• Restart the PC and observe the complete sign-in and application launch sequence.

• Verify the control interface loads its configuration under the operator account.

• Check that the public interface cannot reach unapproved administrative tools.

• Exit through the supported maintenance process and return to operation.

• Test password rotation and a pending update restart on a bench or maintenance system.

• Confirm what happens when automatic sign-in fails or the application closes.

Accept the design when unattended behavior meets the actual requirement, public access is appropriately restricted and maintainers retain a documented recovery path. Record each feature's edition dependency in the bill of materials.

Use headless display considerations for the separate graphics and remote-session problem. Integrators can discuss deployment requirements with the edition, application and account model already identified, without assuming a built in kiosk management feature.