Give each person an individual account with the least capability required, document the removal time and verify revocation; native role selection is not automatic account expiration.
Give temporary WordPress access through a separate named account, using the smallest role that can do the agreed task. Record when the work ends, verify what the account can and cannot do, and remove access deliberately. Choosing a native WordPress role does not make that account expire automatically.
This is a documented workflow for a site owner or authorized administrator. It does not demonstrate access changes on a real customer site. Test important permission boundaries in a private copy first, especially when plugins, custom roles, a store or a WordPress network are involved.
Start with the task, not the job title
“Freelancer” and “developer” are not permission levels. A freelancer who writes a draft needs different access from a developer replacing a plugin. Write down the pages, actions and environment involved before creating the account. Ask what requires access rather than defaulting to Administrator because someone requested it.
For example, a fictional studio at example.com hires a writer to prepare three draft articles. The agreed job excludes publishing, editing other writers’ articles, changing forms and installing software. That makes draft creation the initial capability to test. If the writer needs images, the owner can supply them or review a narrower custom arrangement; broadening access is a separate decision.
For a layout or code change, begin in staging when practical. Provide synthetic content or remove unnecessary private records. Copying the full production database can expose customer information even if the account cannot administer plugins.
What the core roles usually permit
WordPress’s role documentation defines capabilities rather than a simple seniority ladder. These are the standard single-site starting points; effective access must still be checked on your installation.
| Role | Typical fit | Boundary to notice |
|---|---|---|
| Subscriber | Account/profile access | Does not provide article-writing capability |
| Contributor | Write own drafts for review | Cannot publish or upload files by default |
| Author | Publish and manage own posts | Includes more than draft submission |
| Editor | Manage editorial content across writers | Can affect others’ content |
| Administrator | Authorized site administration | Broad site control; unsuitable as a default for writers |
Multisite adds network-level Super Admin responsibilities. An ordinary site administrator and a network administrator are different scopes. A plugin can add capabilities, change roles or protect its own records differently; a familiar role name alone is not proof of least privilege.
1. Create an individual account
As the authorized administrator, open the site’s user-management area and use its current add-user workflow. Confirm the correct website and environment, the person’s verified email address and the chosen role before saving. WordPress documents manual user creation; the current password-setup controls can differ from older help illustrations.
Have the person set a unique strong password through the supported private invitation or reset process. Do not send your own administrator password or put credentials in a project document. If the site supports an appropriate additional authentication method, apply it according to that method’s instructions.
For one invited contractor, there is no need to enable unrestricted public registration. Check the default registration role separately if registration is already part of your website. One manually created account should not accidentally change who can register next.
2. Record scope and the removal time
Keep a short access note: person, purpose, environment, approved tasks, account identifier, start time, end time and the owner responsible for revocation. Do not store passwords in that note. Agree a handover checklist so the owner can judge whether the task is complete.
Native role selection has no built-in expiry field in this workflow. Use a reliable reminder and an accountable human to remove access at the agreed time. If you choose an access-expiration plugin or hosting feature, verify its current behavior in staging, including scheduled-job failures and emergency revocation. Do not assume that an expiry label proves the login will stop.
A WordPress account also does not grant or revoke hosting, domain, DNS, email or repository access. Track any separately authorized services individually; completing the WordPress step leaves those other relationships unchanged.
3. Verify allowed and denied actions
Have the person confirm their own login, then check the agreed workflow with harmless sample data. For the fictional writer, save and reopen a synthetic draft. Confirm that the account cannot publish it, install plugins or edit another person’s article. Use the private copy for permission probes that could otherwise change content.
Check the interface and the action result together. A hidden menu is not sufficient evidence that an operation is forbidden. Where a plugin provides its own dashboard or direct editing URL, verify the actual outcome using that plugin’s documented controls.
If an expected action fails, identify the missing capability before promoting the account. If an unexpected action succeeds, pause the work and review custom roles, plugins and ownership. Restore the smallest appropriate access after the reason is understood.
4. Review the handover before offboarding
Review draft ownership, changed settings, new integrations and any credentials created during the task. Request a concise record of the changes. Do not accept an additional administrator or an unexplained plugin as a necessary part of a writing handover.
WordPress’s hardening guidance supports limiting and protecting access as part of layered security. An ordinary account gives traceable ownership and makes revocation manageable; it cannot make an untrusted person safe to administer production.
5. Remove access while preserving the work
At the agreed end, use the appropriate user-management action. Changing an Administrator to Subscriber reduces capabilities but still leaves an account that can log in. If the job requires access to end, verify that the selected removal or supported disabling method actually achieves that.
Deleting a user presents a content choice. Review it carefully and attribute the person’s existing content to the intended account when it must be retained. Do not select deletion of authored work merely to remove login access. Plugin-owned orders, memberships and audit records may need their own documented handling.
Review any application passwords or other integration credentials created for the task and revoke those that are no longer needed. These are separate from a normal browser-login password. If a shared credential was used despite the individual-account workflow, rotate it through the service’s supported procedure.
Verify the old account cannot perform the former work, including an already-open session where relevant. Check that retained articles still have the intended owner and display correctly. Record the removal time and remaining separately managed access, then close the access note.
Common questions
Is Editor a safe role for every contractor?
It can change other writers’ content. Choose it only when that is part of the job and verify plugin-specific access.
Can I keep an unused administrator for next time?
An unnecessary privileged account remains access to maintain. Remove or appropriately restrict it, and create a fresh approved arrangement when another task begins.
Does a password reset revoke every integration?
Do not assume it does. Review application passwords, external services and the site’s authentication method separately.
What if temporary access removes the owner’s access?
Keep a verified owner recovery route outside the temporary person’s account. If ownership or recovery is uncertain, resolve that before granting administrative privileges.
Prepare recovery and a controlled change
Read the WordPress recovery guide before administrative work, then use the private-copy test workflow. For broader operating costs, review the security and backup budget guide.
Sources and verification
Editorial review 2026-10-08. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: roles and capabilitiesChecked Core role capabilities differ by task; Contributor cannot publish, Author manages own posts, Editor manages others' posts and Administrator has broad site access.
Limits: Plugins, custom roles and Multisite can change effective permissions. The default role model does not itself schedule account expiry. - WordPress: add a userChecked An administrator can create an individual user and assign a role.
Limits: The help page includes older interface examples; use the actual supported password setup flow rather than assuming its screenshots match. - WordPress: users screenChecked Role changes and user deletion are available; deletion presents a choice to remove or attribute authored content.
Limits: Changing a role is not equivalent to deleting login access. Multisite removal and plugin-owned data can differ. - WordPress: hardeningChecked Limit access, protect credentials and apply layered security practices.
Limits: General guidance does not certify a contractor, a hosting setup or a specific authentication product. - WordPress Core: application passwords integration guideChecked Application passwords are separate API credentials that can be viewed and revoked from the user-editing interface.
Limits: Historical feature introduction; availability and interface depend on the current site. They are not human wp-login passwords. - WordPress: development copyChecked A development installation provides a place for testing away from live work.
Limits: A copy needs independent data and controlled integrations; private access does not automatically anonymize its contents.