When a relationship with a web agency, freelance developer, or technology provider ends, deleting their WordPress user is usually only part of the work. The provider may retain access to the domain, hosting, backups, transactional email, code repositories, or integrations that allow them to modify the website or view operational data.
The specific challenge is removing that access without making a store, forms, order notifications, or domain renewals inoperative. The solution is not to revoke everything at once: it requires identifying dependencies, securing internal control first, and applying a documented and verifiable closure.
The Real Scope of a Web Provider’s Access
A corporate website or e-commerce site normally depends on several connected services. In addition to the CMS administrator, there may be accounts with the domain registrar, DNS management, hosting or cloud provider, a CDN, an application firewall, payment platforms, email tools, CRM, analytics, monitoring, and backup systems. Each service may have its own users, tokens, keys, or recovery mechanisms.
The first risk of a rushed closure is disruption: disabling an account that renews an API credential can stop orders from being sent to the ERP; removing a recovery email can make it impossible to recover a critical account. The second is unknowingly retaining residual access. OWASP recommends applying least privilege, reviewing permissions periodically, and denying access when there is no explicit authorization. [2]
Prepare an Inventory Before Revoking Any Access
Before changing passwords or deleting users, compile an inventory of assets and access. For each asset, note the service, URL or identifier, internal owner, administrators, provider with access, operational use, recovery method, and planned removal date. This record makes it possible to decide the order of changes and reduces reliance on information scattered across emails or conversations.
At a minimum, include the domain and DNS; hosting, cloud, CDN, and WAF; WordPress and the store; payments; outgoing email and forms; CRM and automations; backups, alerts, and monitoring; repositories; SSH keys; API tokens; OAuth applications; and webhooks. It is also advisable to record active sessions and service accounts, because they are not always removed when a CMS user is deleted.
- Assign an internal owner and a backup person to each critical asset.
- Distinguish between personal accounts, shared accounts, service accounts, and integration credentials.
- Mark which services affect sales, customer service, campaigns, backups, or domain renewal.
Secure Ownership, Recovery, and MFA Within the Company
The company should hold administrative ownership of its critical assets, even if it delegates their operation. Before removing the provider, verify that at least two authorized people in the organization can administer or recover the most sensitive accounts through separate channels. NIST states that active accounts should be maintained as unique identities and associated authenticators should be recorded; having more than one authentication method reduces dependence on a single recovery process. [1]
Review recovery emails and phone numbers, backup keys, and multifactor authentication factors. CISA recommends enabling MFA wherever possible, starting with administrative accounts and access that handles sensitive information. If an MFA factor must be replaced, do so through a validated procedure: OWASP warns that this change is a risky action and recommends requiring new authentication with an already registered factor and notifying through an independent channel. [3] [4]
Carry Out Removal in Phases and with Operational Testing
A prudent sequence is to first create named internal accounts, validate that they work, and then reduce the provider’s permissions until they are removed. Replace shared accounts with personal accounts holding the minimum role required. For technical credentials, plan a rotation: generate a new key or token, update the authorized integration, confirm that it works, and only then invalidate the previous item.
Hypothetical example: a WordPress store sends orders to an ERP through an API configured by its agency. Rather than immediately deleting the provider, the team identifies the credential in use, creates a new one under company control, updates the configuration in an agreed environment or change window, and verifies that an authorized test order reaches the correct destination. After that, it revokes the old token and the agency’s administrative access.
- Check access to the domain before modifying DNS or hosting.
- Verify forms, payments, orders, transactional emails, and backup restoration after every relevant change.
- Close active sessions where the service allows it, and remove SSH keys, tokens, OAuth applications, webhooks, and repository permissions.
Document the Closure and Review Remaining Access
Record every closure action with the affected asset, the removed account or credential, the responsible person, the date, the replacement applied, and the test performed. This record does not replace a full audit, but it makes it easier to respond to incidents and determine what remains pending. Also keep operational instructions up to date, without including secrets in documents that are indiscriminately accessible.
After the change, schedule an authorized review of accounts, permissions, and available logs to confirm that no unnecessary access remains. CISA recommends removing accounts that are no longer needed, periodically reviewing whether accounts are still necessary, and applying least privilege. If the inventory reveals unknown configurations or critical dependencies, a web protection audit with an agreed scope may help prioritize defensive fixes without affecting operations. [5]
Frequently asked questions
Is it enough to remove the agency as a WordPress administrator?
Not necessarily. That action does not by itself revoke access to hosting, the domain, DNS, backups, repositories, transactional email, service accounts, API tokens, OAuth applications, or active sessions. Review every asset included in the inventory before considering the closure complete.
Should I change all passwords when the relationship ends?
Prioritize critical accounts and those that have been shared or managed by the provider. In addition to passwords, review recovery methods, MFA, SSH keys, tokens, and integration permissions. The change should be carried out in phases to avoid breaking services that depend on a previous credential.
What should I do if I do not know who controls the domain or an integration?
Do not remove access blindly. Identify the registrar, ownership details, recovery accounts, and current responsible parties. For an integration, determine which system uses it, which credential it operates with, and how its operation is validated. If there is significant technical uncertainty, define an authorized review before applying changes.