Give a WordPress Developer Access Safely—and Remove It Properly

Security guidance · References checked 2 November 2026

In this guide

1. Define the task before creating accounts
2. Use named accounts with appropriate permissions
3. Keep hosting and domain ownership separate
4. Protect interactive logins and integration credentials
5. Set production-change and data-handling boundaries
6. Make handover a deliverable
7. Remove access across all systems at the end
8. Keep ongoing support explicit

A developer may need access to fix a website, but “send me every password” is not a useful access plan. The right arrangement identifies the job, the systems involved, who approves the work and how temporary access will be removed. That protects the business and gives the developer a clear working boundary.

This guide covers access for development, maintenance and recovery projects. The same approach can be adapted for an agency or an internal team. It does not assume that every project needs administrator, hosting, database and domain access simultaneously.

Define the task before creating accounts

Describe the work in plain language: adjust a page, repair a form, update an extension, investigate malware or configure an integration. Record the website, expected changes, approval process and any restrictions on production activity.

Ask the developer which systems they need and why. A content change may fit a limited website role; a hosting-level incident may require a different route. Do not give registrar or payment-account access merely because it appears on a generic onboarding checklist.

Separate investigation from permission to make consequential changes. Agree before removing data, switching payment modes, changing DNS or deploying a substantial change. A useful work order also identifies the backup owner and the person who can approve a rollback during an outage.

Use named accounts with appropriate permissions

Create an individual account for each person where the platform supports it. Keep ownership under a business-controlled contact, and record the purpose, approver and review date. Shared accounts make it harder to attribute actions and to remove one person without affecting others.

WordPress’s roles and capabilities documentation provides the basis for choosing access. Custom roles and plugins can change actual capabilities, so verify what the selected role permits. Do not assume a familiar role name means the same access on every installation.

Give access for the required work rather than permanently promoting everyone to administrator. If a temporary elevation is needed, document the reason and when it will be reviewed. Confirm that the business owner retains an independent authorised administration route.

Keep hosting and domain ownership separate

A WordPress account, an SFTP/SSH account and a domain registrar account are different access paths. Removing one does not revoke the others. Use the host’s supported collaborator or scoped-account features when available, with access limited to the relevant site and task.

Keep the domain, hosting and important commercial licences under the business’s ownership unless another arrangement is explicitly agreed. A developer can administer a service without becoming its only recoverable owner. Confirm how the owner would regain control if the provider changed or the relationship ended.

Use protected transfer methods for any necessary secrets. Do not place them in a public enquiry form, an article comment, a shared screenshot or a project document available to unrelated people. Ask which people and tools will receive access, including subcontractors or automation, before sharing.

Protect interactive logins and integration credentials

Use a strong unique password and the supported additional authentication method for privileged interactive accounts. Agree the recovery process before enforcement so a lost device does not lead to a rushed bypass. The MFA setup guide explains a careful rollout.

An integration that needs API access should use the platform’s supported authentication method. WordPress documents Application Passwords for appropriate programmatic access over HTTPS; this is different from giving an automated tool a person’s primary browser-login password. WordPress REST API authentication.

Name each integration clearly and record its owner and purpose. Do not reuse a single secret across unrelated tools. Keep credentials out of front-end code and logging payloads. The ability to disable a specific integration later is part of the original design, not an optional handover extra.

Set production-change and data-handling boundaries

Agree whether the developer will work on staging, production or both. Identify which actions can send emails, create orders, affect live payments or disclose customer data. Testing needs a controlled plan as well as access.

Use synthetic or appropriately minimised information where real records are unnecessary. If troubleshooting requires sensitive material, agree the smallest useful dataset, secure storage, permitted recipients and what happens to the copy after the project. A complete production database is not automatically necessary for a design adjustment.

Keep a change record with the relevant backup reference and deployment steps. This helps the next maintainer understand which files, plugins or settings are intentionally different from a standard installation.

For configuration and file-level work, include ownership and permissions in the review. The file-permissions guide explains why access should match the host’s architecture rather than a universal permission command.

Make handover a deliverable

Ask for a concise record of the work completed, the systems touched, software or licences introduced, configuration changes, tests performed and unresolved issues. Confirm where source code, deployment instructions and backups are stored, and who can retrieve them.

Have the owner or designated maintainer demonstrate the tasks they will need: sign in, publish an approved change, find a backup reference or identify the support route. A folder of documentation is less useful if nobody knows which instruction applies to the current system.

An example handover for a repaired enquiry form would identify the form handler, delivery destination, spam controls and the verified test result, while keeping credentials in protected storage. This is a planning example, not a claim about a completed client project.

Remove access across all systems at the end

Use the original access register as the offboarding checklist. Review WordPress users and sessions, hosting collaborators, SFTP/SSH access, deployment keys, API credentials, repository access and any provider dashboards involved in the work. Reassign necessary content or ownership before deleting an account.

Revoke credentials that are no longer required, and coordinate rotation of any shared secrets that were disclosed. Test the legitimate integration after a coordinated change. Do not remove an active automation credential without understanding what it runs.

OWASP’s authentication guidance treats account recovery and risk-related authentication controls as part of the overall system. Your project checklist should similarly account for existing sessions and recovery routes, not just a password field.

Keep ongoing support explicit

If access continues for maintenance, record the service scope, responsible person, permitted activity and next review. Ongoing access should be a deliberate agreement, not a forgotten administrator left behind after a one-off job.

Verify that the owner still controls the site and that the completed changes continue working after offboarding. Keep the handover and access review privately. The result is a clearer working relationship and fewer unmanaged access paths; it is not a guarantee against every future security incident.

Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.