Is it safe to give someone admin access to your WordPress site?

It is as safe as the person, because an Administrator can do anything on the site. Never share your own login. Add a user in their name, let WordPress email them a link to set their own password, and delete the user when the work is done.

By: WP Ministry
Published: October 10, 2026
Tested on: WordPress 7.1.3, PHP 8.3.35

In short

An Administrator can do anything on a single site, including install code, create users and delete your account. The access is as safe as the person.
A lesser role is enough for content work. An Editor can publish and edit every page and post, and cannot touch plugins, themes, updates, settings or users.
Never share your own login. Add a user in the person's name, with their own email address.
Leave "Send the new user an email about their account" checked. WordPress emails them a link to set their own password, so none passes between you.
An application password keeps working after a password change and a logout. Revoke it, or delete the account.
When the work is done, delete the user and choose "Attribute all content to another user." so that what they made stays.

Giving someone administrator access to a WordPress site is as safe as the person you give it to. On an ordinary single site, an Administrator can do everything you can: install and edit plugins, change any setting, create other users, and change or delete your own account.

What you control is how the access is given. Never hand over your own login. Add a separate user in that person's name, let WordPress email them a link to set their own password, and delete the user when the work is done. Access given that way is access you can see, cut down and take back.

What an Administrator can do

WordPress's documentation describes the Administrator as the role with access to all the administration features of a single site. On a single site, its table of capabilities gives these to the Administrator and to no role below it:

updating WordPress, plugins and themes
installing and deleting plugins and themes
editing the files of plugins and themes
changing the site's settings and switching its theme
creating, editing and deleting users, and changing their roles
exporting the site's content

Two of those reach further than they look.

An Administrator can run code on the server. WordPress's hardening guide says the dashboard by default lets administrators edit the PHP files of plugins and themes, and that this allows code execution. It also says that someone who gets into an administrator account can install scripts that may compromise the entire server. So this access does not stop at WordPress's own screens. It reaches the files and the database behind them.
An Administrator can change who else has access. On a single site there is no role above the Administrator: WordPress's documentation says Administrators there are, in effect, Super Admins. A new Administrator's Users screen offers Delete beside every other account, the first one included.

When a lesser role is enough

Match the role to the work.

The work	Role	What the role can and cannot do
Writing, editing and publishing any page or post	Editor	Publishes, edits and deletes every page and post, manages categories, moderates comments and uploads files. No access to plugins, themes, updates, settings or users.
Writing their own posts	Author	Publishes and manages their own posts and uploads files. Cannot edit pages or anyone else's posts.
Drafting posts for you to publish	Contributor	Writes and manages their own posts. Cannot publish them or upload files.
Running a WooCommerce store day to day	Shop Manager	A role WooCommerce adds, for managing a store without full Administrator access: products, orders, coupons, reports and WooCommerce's settings.
Updating, installing, changing settings, tracing a fault	Administrator	Everything on the site.

An Editor is not harmless. An Editor can delete any page, and on a single site holds the unfiltered_html capability, which WordPress describes as letting a user put HTML markup or even JavaScript code into pages and posts. But an Editor cannot install anything, change a setting or touch another account.

A lesser role is not enough for maintenance or repair. Updating WordPress, a plugin or a theme, switching a plugin off to trace a fault, changing a menu or a setting: each takes an Administrator, and no smaller role will do. On a multisite network, installing and updating belong to the Super Admin and not to a site's Administrator.

So you cannot make this access safe by choosing a smaller role. You make it safe by choosing the person, and by giving the access in a form you can take back.

You could not tell their work from yours. Every change, every login and every revision would carry your name.
You could not take it back. The only way to end a shared login is to change your own password. Until you do, whoever holds it can change the password, or the email address on the account, and lock you out.
The password would outlive the job. A password sent by email or chat stays in those messages, on their side and on yours.

A separate account has none of these problems.

Add a user for them

Step 1: Open Users, then Add User
Log in as an Administrator. In the dashboard menu, go to Users, then Add User.
Step 2: Enter a username and the person's own email address
Choose a username that says who it is, such as dana-developer. WordPress does not let a username be changed later.

For the email, use the person's own work address. WordPress sends the link to set a password to that address, and whoever reads that mailbox can use it. Confirm the address with the person before you type it.
Step 3: Leave the password alone
WordPress fills in a generated password. You do not need to copy it or send it to anyone.
Step 4: Leave "Send the new user an email about their account" checked
It is beside "Send User Notification", and it is checked when the screen opens.
Step 5: Choose the role
The Role list starts at the site's default for new users, which is Subscriber unless someone changed it. Choose Administrator if the work needs it, or the lesser role from the table above.
Step 6: Select Add User
The Users screen opens with the notice "New user created."

WordPress then sends two messages.

To the person: the subject is your site's title in square brackets, then "Login Details". The message reads "To set your password, visit the following address:" and gives a link. They open it and choose a password that you never see. By default the link works for one day, and it stops working once it has been used.
To the site's administration email address: "New User Registration", with the new username and email address.

When the person saves their password, the administration address gets a third message, "Password Changed", which reads "Password changed for user:" and the username. That is your sign that the account is in use.

If the link ran out before they used it, go to the Users screen, hover over the account and select "Send password reset". If no message arrives at all, the site may not be sending mail: see how to fix WordPress not sending email. Fix that before you fall back on a password in a chat message.

With WP-CLI, one line does the same. How to use WP-CLI to manage a WordPress site covers getting set up.

bash

wp user create dana-developer dana@example.com --role=administrator --send-email --porcelain

--send-email sends the same messages as the checkbox. --porcelain makes WP-CLI print only the new account's ID. Without it, WP-CLI prints the generated password on a line that begins "Password:", which nobody needs.

Ask the person to turn on two-factor authentication for the account. WordPress's hardening guide calls it a good idea on top of a strong password, and how to set up two-factor authentication in WordPress has the steps.

What you can see and change afterward

Who is an Administrator

On the Users screen, select the Administrator link above the table. It shows the number of administrators and lists them. With WP-CLI:

bash

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

You should be able to put a name to every account listed. An Administrator can create other users, so look at this list again while the work is going on. If an account is there that nobody can explain, read what an unknown admin user means and how to remove it properly before you delete it.

Where an account is logged in

WP-CLI lists an account's open sessions. Each row is one login that is still open: when it began, when it expires, the IP address and the browser.

bash

wp user session list dana-developer --fields=login_time,expiration_time,ip,ua

It is a list of logins that are open now, not a history. A login lasts two days, or 14 days if "Remember Me" was checked, and a session that has expired or been ended is no longer listed. The dashboard has no such list.

WordPress shows you the account, its open sessions and, on each revision of a page or post, who saved it. For anything else that was done, its hardening guide points to the server's logs, which give an IP address and a time and not a username, and to security plugins that keep an audit trail.

Log an account out

On the Users screen, select Edit under the account. Under "Sessions" there is one button, "Log Out Everywhere". The row is there only while the account has a session open. With WP-CLI:

bash

wp user session destroy dana-developer --all

The person's browser is sent back to the login page on its next request. This does not stop them logging in again, and it does not touch an application password.

Change the role down

Someone who stays on to edit pages does not need to stay an Administrator. On the Users screen, select the checkbox beside the account, choose Editor under "Change role to…" and select Change. With WP-CLI:

bash

wp user set-role dana-developer editor

The change applies at once, to a browser that is already logged in as well. On the Plugins screen that person now reads "Sorry, you are not allowed to access this page."

Application passwords

An application password is a credential WordPress makes for a program, such as a management dashboard or a reporting tool, so that it can act as one user through the REST API. WordPress's documentation gives its properties: it is tied to one user account, it is shown once when it is made, it cannot be used on the login page, and each one can be revoked by itself.

A program that holds one acts with that account's role. Lower the role and the program is limited with it.

What catches people out is what does not remove one. An application password keeps working after the account's password is changed, after the account is logged out everywhere, and after the site's security keys are replaced. Only revoking it, or deleting the account, ends it.

Look for them on the account's Edit User screen, under "Application Passwords". The table has the columns Name, Created, Last Used and Last IP, a Revoke button on each row, and a "Revoke all application passwords" button below. The section needs HTTPS: without it, the screen says "The application password feature requires HTTPS, which is not enabled on this site."

With WP-CLI, list them, then revoke one by its uuid:

bash

wp user application-password list dana-developer --fields=uuid,name,created,last_used,last_ip

bash

wp user application-password delete dana-developer 6633824d-c1d7-4f79-9dd5-4586f734d69e

created and last_used are printed as Unix timestamps. Put --all in place of the uuid to revoke every one the account has.

Access beyond WordPress

A WordPress account is one way in. The hosting control panel, SFTP or SSH, and the database are others, and each is given and removed separately.

The hosting account. Ask your host whether it can give a second person a login of their own, so that you do not share yours. Some hosts can, and say so in their documentation. WP Engine's, for one, describes inviting account users with roles, and Kinsta's describes roles for a whole company or a single site, including a developer role that does not see billing details.
Files. WordPress's hardening guide says to connect with SFTP where the host provides it, so that the password is encrypted on its way. Where the host lets you, give the person an SFTP user or an SSH key of their own, and remove it afterward.
The database. Anyone who can read the site's files can read wp-config.php, which holds the database connection details, the password among them. File access is database access.
What they do not need. Work inside WordPress does not call for the domain registrar, your billing details or your own mailbox. If someone else already holds those for you, how to take over a WordPress site when your web developer has disappeared explains what to move into your own name.

Removing one way in does not remove the others. WP Engine's documentation says as much of its own platform: deleting a user from the hosting account does not delete WordPress users or change SFTP users. Keep a note of each thing you hand over, with the date. At the end, that note is your list.

Where something has only one login, share it through a password manager and not by email or chat, and change the password when the work ends.

Questions to ask before you give access

Put these to anyone you are about to let in, whether a developer, an agency or a support desk.

Who exactly will use this account? Ask for a name, not "the team".
Will anyone else log in with it? A login shared among staff cannot be traced to a person, and it cannot be taken away from one person.
Where will the login be kept? In a password manager, in a shared document, in someone's inbox? Who can open it?
Is two-factor authentication turned on for it?
Will any program connect to the site? If a tool of theirs needs an application password or a plugin of its own, ask what it is called, so that you can find it and remove it later.
What else do you need besides WordPress, and what for?
When will the account be removed, and who will tell me the work is done?

Good answers are specific. You can check some of them yourself. With one account for each named person, the Users screen is the list of who can log in.

An agency handing its clients' sites to a partner has more to settle. Should you outsource WordPress maintenance? covers that case.

When the work is done

1
Step 1: Delete the user
On the Users screen, hover over the account and select Delete. If the account made anything, WordPress asks "What should be done with the content owned by this user?" Choose "Attribute all content to another user.", pick yourself from the list, and select Confirm Deletion.

Content here is more than posts. It includes the images the account uploaded and the revisions of every page it edited. The other choice, "Delete all content.", moves the account's posts and pages to the Trash and deletes its uploads outright, files included. A page that used one of those images is left pointing at a file that is gone.

If the account made nothing, the screen says "This user does not have any content." and there is only the button.

With WP-CLI, --reassign takes the ID of the account that inherits the content. Here it is 1.

Without --reassign, WP-CLI asks you to confirm and then does what "Delete all content." does.

Deleting the user ends its sessions and removes its application passwords with it.
bash
```
wp user delete dana-developer --reassign=1
```
Step 2: List the administrators again
An Administrator can make other accounts. Open the Users screen, select the Administrator link, and check that every account left is one you know.
Step 3: Remove what was installed for the job
A plugin that connected the site to someone's dashboard, a tool for temporary logins, a debugging plugin: if you do not need it, deactivate and delete it.
Step 4: Close the other ways in
Remove their user from the hosting account, and their SFTP user or SSH key. Change any password that was shared. If they had access to the files, they could read the database password, so change that as well, at the host and in wp-config.php together. The same guide to taking a site over lists every password and key worth changing, in order.

If you are the one who ends up locked out, your hosting account is the way back, and how to get back into WordPress when you are locked out has the steps.

Common questions

Can I give access that expires by itself?

Not with WordPress alone. The Add User screen has no end date, and an account stays until someone deletes it. Plugins exist for this. Temporary Login Without Password, for one, describes itself as making a login link with a role and an expiry that you choose. A plugin like that is one more thing to trust and to remove afterward. Otherwise, put the removal date in your calendar on the day you create the account.

Can an Administrator lock me out of my own site?

Yes. An Administrator can change any account's role, password or email address, and can delete any account but the one they are logged in with. What protects you is the hosting account: whoever controls the hosting can let themselves back into WordPress. Keep that login to yourself, and see how to get back into WordPress when you are locked out.

I changed the password on their account. Is that enough?

No. The email address on the account is still theirs, so "Lost your password?" on the login page sends them a link to set a new one. An application password made under the account is not affected at all. Delete the account. If it has to stay, change its role down and revoke its application passwords.

A plugin's support team has asked for admin access. What should I do?

Treat them like anyone else. Create an account for them with the address they give you, leave the notification checked, and delete the account when the ticket is closed. If the fault also shows on a staging copy of the site, give them access there instead. A staging copy still holds the same users and customer records, so remove that account too.

Is it safe to give someone admin access to your WordPress site?

In short

What an Administrator can do

When a lesser role is enough

Add a user for them

Step 1: Open Users, then Add User

Step 2: Enter a username and the person's own email address

Step 3: Leave the password alone

Step 4: Leave "Send the new user an email about their account" checked

Step 5: Choose the role

Step 6: Select Add User

What you can see and change afterward

Who is an Administrator

Where an account is logged in

Log an account out

Change the role down

Application passwords

Access beyond WordPress

Questions to ask before you give access

When the work is done

Step 1: Delete the user

Step 2: List the administrators again

Step 3: Remove what was installed for the job

Step 4: Close the other ways in

Common questions

More on this subject

Quick Fix, done for you