User 1
User 1 is the Drupal account with user ID 1, created at install. By default it skips every permission check, so use it for recovery, not everyday editing.
User 1 is the first account created when a Drupal site is installed: the one whose password you choose in the installation wizard. Its user ID is 1, and that number gives it a special status. By default Drupal skips every permission check for it, so it can reach any page and change any setting, whatever roles it holds.
What makes user 1 different
Every other account gets its access through roles, and each role is a list of permissions. User 1 needs neither. Drupal core has an access policy for it, SuperUserAccessPolicy, that grants everything to the account with user ID 1. That is why a stolen user 1 password is worse than a stolen editor password, and why sharing it is a risk.
The numbering is simple. The anonymous visitor uses user ID 0, the installer account is 1, and accounts created later get higher numbers.
Turning the superuser behavior off
Since Drupal 10.3.0 the behavior can be switched off. Add the parameter below to the site's services.yml, then rebuild the container, for example with drush cr.
parameters:
security.enable_super_user: false
With the parameter set to false, user 1 is an ordinary account that has only the permissions of its roles. Make sure an account with the Administrator role exists before you switch it off. If you lock yourself out, set the value back to true and rebuild the container.
How to use user 1 safely
- Do not use it for daily work. Create a named account with the Administrator role for each person who manages the site, so the site log shows who changed what.
- Give it a long, unique password kept in a password manager.
- On a production site, you can block the account once named administrators exist. Block it rather than delete it. To get back in, unblock it with
drush user:unblock --uid=1and request a login link withdrush user:login.
Common mistakes
- Sharing the user 1 password with the team. Anyone who has it has unlimited access, and the log cannot tell their actions from yours.
- Editing content as user 1 because it just works. An account that skips permission checks hides missing permissions, so a role problem shows up only when a real editor runs into it.
- Deleting the account. Its content then either moves to the Anonymous user or is deleted with it. A blocked account cannot log in either, and blocking can be reversed.
For marketing and content teams
If you edit content on a Drupal site, you should never need user 1. Ask your developers for an account with the roles your work needs, such as editor or content approver. If someone offers you the user 1 login, ask for a personal account instead: a shared login makes it impossible to see who published or changed a page.