Securing the admin super user (#1)

The Drupal account created during installation (user #1) is a special account. Primarily, it bypasses all access callbacks - meaning it has all permissions by default. Failing to secure this account could result in potential security risks. You can think about the user #1 account as you would with root on Linux systems.

There are several options to secure this account:

Use other accounts for normal administration

First, you should create (or use an existing role) for the administrative accounts on the site. Grant only the permissions required to do admin work to this role. Grant this role to just the people who truly need it.

Ensure repeated login attempts are rejected

Protection against brute-force attacks was added to core in Drupal 7. For a configurable interface, use the Flood Control module.

Do not name first account 'admin'

Do not use an obvious name like 'admin' or 'administrator' which are too easy to guess.

Disable it entirely

With the advent of tools like Drush to run the update hooks and the creation of the administer software updates permission, logging in as UID=1 is no longer required.

Disabling login as UID 1 or as admin username

With Drush, you can disable this account by running the following at a command prompt:

drush user:block admin

Replace admin with the name of your admin account if you renamed it.

If you do not have access to Drush, you can run a SQL query instead:

UPDATE users_field_data SET status = 0 WHERE uid = 1;

Note: You need to clear caches before the the Status changes under /admin/people.

Re-enabling UID=1 or as admin username

The following Drush command or SQL statement re-enables the account:

drush user:unblock admin

Replace admin with the name of your admin account if you renamed it.

By default, unblocking a user will send them an Account activation email, configurable under /admin/config/people/accounts.

UPDATE users_field_data SET status = 1 WHERE uid = 1;

Generate a long, randomly generated password for this account

You could set the admin account to a long, hard to guess password to make it less likely the account can be taken over. Generate a long random password using the command line with this:

tr -dc A-Za-z0-9_ < /dev/urandom | head -c 32 | xargs

Note that there are password generators out there that will likely create more secure passwords, including symbols and other characters. Consider using those if you have access to them.

Use the Paranoia module to disable editing this account

The Paranoia module will disable editing of the UID=1 account, preventing someone with access to your site from re-enabling it and then using it to log in and escalate privileges.

Take care to evaluate all of the features of Paranoia: it performs several security and good-practice functions.

Use Password Policy module to enforce restrictions on user passwords

The Password Policy module can be defined with a set of constraints which must be met before a user password change will be accepted. Each constraint has a parameter allowing for the minimum number of valid conditions which must be met before the constraint is satisfied.

Limit access by IP address to only trusted users

The Restrict Login or Role Access by IP Address module can prevent access from untrusted locations.

Disable the super user access policy

Note: Only available in Drupal 10.3 and greater.

User 1's special privileges are now part of the SuperUserAccessPolicy, which can be turned off. From Drupal 10.3.0 onwards, you can toggle this behavior in your site's services.yml file by setting security.enable_super_user to false.

For example:

parameters:
  # Toggles the super user access policy. If your website has at least one user
  # with the Administrator role, it is advised to set this to false. This allows
  # you to make user 1 a regular user, strengthening the security of your site.
  security.enable_super_user: false

If you get locked out of your site, then changing the parameter back to true will make user 1 a super user again.

After changing the parameter the container must be rebuilt. Rebuilding the caches using the user interface, Drush or visiting core/rebuild.php can do this.