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.

Learn DrupalDrupal glossary

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.

How Drupal checks a permission for user 1When Drupal checks whether an account has a permission, the super user access policy asks whether the account has user ID 1. If it does, every permission is granted, whatever roles the account has. If not, the permissions of the account's roles decide. User 1 is the account created at installation, not a role. Setting the security.enable_super_user parameter to false, possible since Drupal 10.3.0, turns the user ID 1 rule off.Drupal checks a permissionDoes this account have 'administer blocks'?Is the account's user ID 1?Asked by SuperUserAccessPolicyyesnoYes: allowedEvery permission is granted,whatever roles the account hasNo: its roles decideAllowed if one of the account'sroles has the permissionUser 1 is the account created at installation, not a role.Setting security.enable_super_user to false (Drupal 10.3.0 and later) turns this rule off.
Every permission check first asks whether the account is user 1: if so, access is granted; if not, the account's roles decide.

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=1 and request a login link with drush 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.

Sources

Questions about User 1

Open the account from the People list. The address of its edit page ends in /user/1/edit, because the number in the address is the user ID.

Yes, if you have command-line access. Run drush user:login to print a one-time login link for user 1, open it, and set a new password. Without Drush, use the Forgot password link with the account's email address.

No, block it instead. A blocked account cannot log in, it can be unblocked later, and the content it authored keeps its author. Create named administrator accounts first, so nobody depends on user 1.

Yes, by default. Drupal 10.3.0 added a setting, security.enable_super_user, that turns the behavior off. Until you set it to false and rebuild the container, user 1 can do everything whatever roles it has.

Related terms

All Drupal terms from A to Z