1:1 Device Assignment
Each Chromebook is assigned to one student, and Google Workspace enforces it at the sign-in screen. Anyone else gets Google's own error message. Free to see every assignment and every gap; Enterprise to enforce.
What it does
Google Admin already has the lock. Under Devices › Chrome › Settings › Device settings › Sign-in restriction, a Chromebook can be limited to a list of named users, and, in Google’s words, “only users that you designate can sign in to devices. Other users get an error message.”
The catch is that device settings apply to an organizational unit, not to a device. One Chromebook for one student means that Chromebook needs its own OU with that one student listed. For a district, that is thousands of OUs, created by hand and redone at every swap, which is why almost nobody does it.
UserAuthGuard does that bookkeeping. When you assign a device, it:
Creates an OU for the device
Named by the device’s serial, inside a parent Assigned OU that you choose. Filtering, apps and network settings are inherited from the parent, so policy stays in one place.
Sets the sign-in restriction to that student
Google’s own SignInRestriction policy on that OU names the one allowed account. Enforcement happens on Google’s sign-in screen, before any session starts.
Moves the device in and records the owner
The device moves into its OU and the annotated user in Google Admin is set to match, so Google’s records and yours agree.
Follows the device through its life
Reassign or return it and the allowed user moves with it, with a dated history of who held it before. Unassigned, repair, loaner and missing devices each have their own OU with its own rules.
| At assignment | An inventory record | UserAuthGuard |
|---|---|---|
| Record who has the device | Yes | Yes |
| Give the device its own OU under your Assigned parent | No | Yes |
| Set Google’s sign-in restriction to that student | No | Yes |
| Set the annotated user in Google Admin | No | Yes |
| Show the owner on the sign-in screen | No | Yes |
| Keep a dated history of who held it | Sometimes | Yes |
- ✓ Enforced by Google, not by an agentThe restriction is a device policy on Google’s sign-in screen. There is nothing on the Chromebook for a student to disable.
- ✓ Policy stays in one placeOnly the allowed user is set per device. Everything else is inherited from the parent OU you already manage.
- ✓ Assignment gaps, on the Free planEvery device with no owner, every student with no device, and every device whose annotated user disagrees with your records, before you pay for anything.
- ✓ The owner on the sign-in screenAn optional sign-in wallpaper names the student and shows the serial and a return code, so a Chromebook left in a hallway finds its way back.
- ✓ One action, not two systemsAssign once. The OU, the restriction and the annotated user are written together, so the record and the device never drift apart.
Requires
- Google Workspace for Education, with UserAuthGuard authorized as a Google Admin app.
- A parent Assigned OU that UserAuthGuard may create child OUs under.
- Guest mode and managed guest sessions turned off on those OUs. Google notes that both bypass the sign-in restriction.
- The Enterprise plan to enforce. The Free plan shows every assignment and every gap, read-only.
Does not
- Replace Google Admin. Policies still live there; UserAuthGuard writes the OU, the restriction and the annotated user.
- Apply instantly in every case. Changes usually reach the device within minutes, but Google allows up to 24 hours for device policy.
- Stop a student signing in to a device that is not restricted, such as a shared cart Chromebook. It restricts who can use a device, not where a student can sign in.
Where it fits
The assigned-but-open fleet
Devices were assigned in a spreadsheet in August, but any district account can still sign in to any of them. The record exists; the device does not know. With the restriction set per device, the record and the sign-in screen say the same thing.
A student moves buildings
Reassign the device and the allowed user changes with it. If the new building has its own Assigned parent OU, the device moves under it and inherits that building’s settings. No separate trip to Google Admin.
Finding the gaps before collection
Before year-end, the assignment-gap report lists every device with no owner and every student with no device. On the Free plan this is read-only; it is still the list you want before anyone starts scanning.
Frequently asked questions
How is this different from assigning devices in an inventory tool?
An inventory tool records that a student has a serial number. UserAuthGuard also writes that fact into Google Admin as a device policy: the device gets its own OU, the sign-in restriction on that OU names the student, and the annotated user is set. The Chromebook then refuses other accounts at the sign-in screen.
Does this replace the Google Admin console?
No. It uses the Admin SDK and the Chrome Policy API to create OUs, move devices, set the sign-in restriction and set the annotated user. Your content filtering, apps and network settings stay where they are, on the parent OU, and are inherited by each device OU.
Doesn't a few thousand OUs make the Admin console unmanageable?
They all sit under one parent you choose, and they carry one setting each: the allowed user. You never edit them by hand. Everything you would normally change lives on the parent and is inherited. OU Explorer shows the tree with counts so you can see it is in order.
We already have assignments in another system. Can we start from those?
Yes. Export student email and serial number to a CSV and load it through Bulk Assignment. Each row is validated against your Google users and devices before anything is written, and the rows that fail are listed for you to fix.
What about loaners and repairs?
A loaner is an assignment with an end date; the allowed user is set to the borrower and reverts when the loan closes. A device sent to repair moves to a Repair OU with its own settings. Both are covered on their own pages.
What is free, exactly?
Read-only visibility of every device, user and OU in your Google Workspace, plus assignment-gap reporting, with no device cap and no credit card. Enforcing assignment (creating the OUs, setting the restriction, moving devices) is part of the Enterprise plan, priced per student, à la carte.
See every assignment and every gap, free
The Free plan shows every device, user and OU, and where the assignments do not add up. When you are ready to enforce at the sign-in screen, the Enterprise plan is priced per student, à la carte.