How to Review Third-Party Administrator Access on a Business Website

Most teams only discover dangerous third-party administrator access when something breaks, a vendor relationship ends badly, or a former employee surprises everyone by still being able to log in.

Run a quarterly third-party access review that inventories every admin path, classifies each account by owner and business need, removes or downgrades everything non-essential, and assigns clear ongoing oversight.

This isn’t just an IT hygiene task. On a serious business website, who can act as an administrator is a governance decision that directly affects revenue, reputation, and incident cost.

In support work, we have noticed a recurring pattern: the riskiest accounts usually aren’t your current primary agency. They’re long-forgotten tools, ex-staff, or contractors who still have powerful access because no one owned the clean-up.

This article walks you through a practical review you can run with light technical support, then shows when recurring access issues are a signal that you need structured security monitoring rather than another one-off tidy-up.

---

1. Why third-party admin access quietly becomes a security liability

If your site has been through a few agencies, freelancers, or internal owners, you probably have more administrators than you think. The access story usually looks like this:

• Agency A builds the site and creates a few admin logins.
• An SEO contractor asks for access, so they get one too.
• A plugin vendor needs an API key or direct publishing rights.
• Agency B takes over and adds their own accounts but doesn’t remove Agency A.
• A few internal staff leave, but no one closes their accounts because “we might need them.”

Nothing catastrophic happens immediately, so the risk stays invisible.

This is governance, not just IT

When someone can act as an administrator, they can usually:

• Change site settings and themes
• Install or disable plugins
• Manage users and permissions
• Connect or disconnect third-party tools
• Access sensitive data or forms

That’s not just a technical convenience. Those are business decisions.

If leadership treats admin access as “whatever the last vendor set up,” you’re in what we call early-stage Maintenance Maturity: mostly reactive, with little recurring review or ownership. Over time, this is how governance collapse starts:

• Shared generic logins like [email protected] become normal.
• No one can say, confidently, who can change DNS or hosting.
• Old vendors still have keys to production systems “just in case.”

Once the site hits a certain scale, that mix becomes a liability. Even if nothing is actively compromised, it slows down every future change and incident.

---

2. Map every way a third party can act as an administrator

Before you can make decisions, you need a full picture of how outsiders can act as admins — not only in the CMS.

Here’s a simple inventory structure you can run in a spreadsheet or shared doc. Aim to map these layers:

a) CMS and site management

For WordPress or similar systems, list:

• All user accounts with roles like Administrator, Super Admin, or equivalent
• Any lower roles that still allow plugin/theme changes or user management
• Single sign-on (SSO) paths if vendors log in via Google, Microsoft, or Okta

Capture for each:

• Name / username
• Email address
• Role / permission level
• Person or company behind the account
• When it was last used, if visible

b) Hosting, servers, and deployment

Next, capture who can change or deploy the site, even if they never touch the CMS:

• Hosting control panel accounts (e.g., server, database, file manager)
• SFTP / SSH logins used by developers or agencies
• Deployment tools (e.g., CI/CD pipelines, automated deploy scripts)
• Backup and snapshot tools that can restore older versions over the top of current content

For each, record:

• Platform name (hosting provider, Git platform, etc.)
• Type of access (control panel admin, read-only, deploy-only)
• Which vendor or internal role owns it

c) DNS and domain registrar

Few people think of DNS as “admin access,” but the person who can change DNS or domain ownership effectively controls your website.

Inventory:

• Domain registrar accounts
• DNS providers or control panels
• Any third-party with delegated DNS management

If a previous agency or IT contractor controls these and the relationship has ended, that’s an urgent risk.

d) Third-party tools with publishing or admin rights

Many tools can change the live site without ever logging into WordPress or your primary CMS. During audits, we often see:

• Marketing automation platforms that can inject forms or scripts
• A/B testing or personalization tools that rewrite page content
• Tag managers with permissions to add arbitrary scripts
• Social or content tools with direct publishing or editing rights

Our supporting piece on related guidance on what to review before giving a third party tool direct publishing access to the website works well as a prerequisite if you want a deeper look at tool-specific risks before you audit them.

e) Shared credentials and informal access

Finally, list:

• Shared email inboxes that receive password resets
• Password manager vaults shared with agencies or contractors
• Any “just log in as me” arrangements

Shared generic logins are usually the clearest sign that governance is slipping. You can’t confidently disable one person’s access without affecting others.

---

3. Classify each admin connection by owner, purpose, and risk

Once you’ve mapped everything, the raw list is overwhelming. The useful move is classification.

Think in three labels for each account or connection:

1. Owner – Who is accountable for this access today?
2. Purpose – What current business need does it serve?
3. Risk – What happens if it’s misused or compromised?

Owner: name a human, not a company

Every admin path should have a named owner on your side, not just a vendor name.

Use owner categories like:

• Internal champion – A marketing lead, product owner, or IT manager
• Active vendor – Current agency, developer, or specialist
• Former vendor – Past relationships where work has ended
• Unknown / unclear – No one on the team can explain it

Any admin access in the “unknown” bucket should be treated as an exception and candidate for removal.

Purpose: tie access to a current outcome

Write a short purpose for each item in plain language, such as:

• “Primary agency deploys theme and plugin updates”
• “Marketing automation syncs MQL form submissions”
• “Legacy SEO plugin from 2019, no longer used”

If you can’t connect an account to a current business outcome, it’s likely legacy risk.

Risk: think by blast radius

Risk isn’t just “high” or “low.” Consider two questions:

• How much damage could this access do if misused?
• How quickly would we notice and recover?

For example:

• A DNS registrar account with registrar admin rights: high blast radius, can take the entire domain offline.
• An overdue freelancer’s WordPress admin account: high blast radius, can alter content, users, and settings.
• A read-only analytics dashboard: low blast radius, mostly data visibility.

Tag high-blast-radius access where the owner is a former vendor or unknown. Those become top priority in the next step.

---

4. Decide what to revoke, downgrade, or keep — with evidence

With classification in place, you can move from intuition to evidence-based decisions.

Here’s a simple decision rule we often see work well in reviews:

If an admin connection has no named owner and no current purpose, or is tied to a former vendor, plan to revoke or downgrade it.

Then, for each item, ask three questions.

Question 1: Who would be blocked if we removed this tomorrow?

Walk through the impact:

• Does any active vendor rely on this account as their only access path?
• Would internal teams lose a critical workflow?
• Do we have another, safer way for them to perform the same work?

If you find that three different agencies all have full admin access to hosting, pick one primary path and plan to close the others.

Question 2: When was this last used — and for what?

Check whatever activity logs are available:

• CMS login history or post revision history
• Hosting last-login data, if provided
• Deployment tool logs

If an account hasn’t been used in months and there’s no clear future project, that’s strong evidence to remove or at least downgrade it.

Question 3: Is the permission level proportionate to the work?

Many accounts are over-privileged. Typical patterns:

• A content editor given full admin rights “just in case”
• An SEO vendor who needs read access but can change everything
• A plugin with full site control when it only needs limited scope

Whenever possible:

• Reassign day-to-day access to lower roles (Editor, Manager, etc.).
• Restrict vendor access to the narrow systems they actually use.
• Separate publishing power from analytics and reporting.

For expansion on checking individual CMS accounts, the article on related guidance on how to verify a wordpress administrator account is still needed shows how to apply these questions to single users when you’re unsure.

A concrete walkthrough: one vendor, multiple systems

Imagine a new marketing leader doing this review on a Friday afternoon. They discover that a past SEO contractor has:

• A personal WordPress administrator login
• Direct access to the hosting panel
• Ownership of a tag management container

After classification, they see:

• The vendor contract ended a year ago.
• No one can explain why they still need any access.
• Logs show no activity for six months.

Evidence says:

• Revoke CMS and hosting access entirely.
• Transfer the tag manager container to an internal owner, then restrict.

That single decision meaningfully reduces risk and simplifies future change.

---

5. Close the loop safely: change credentials, notify vendors, document

Once you’ve decided what stays and what goes, the implementation work needs to be careful. The aim is to tighten access without taking the site down.

Step 1: Take a backup and snapshot of access data

Before you make changes:

• Capture screenshots or export lists of current users and permissions.
• Ensure you have a recent full site backup and, if possible, a restore point at the hosting level.

This gives you a rollback path if something breaks unexpectedly.

Step 2: Sequence changes from lowest to highest risk

Don’t start with DNS or the primary hosting admin.

A typical safe order:

1. Remove clearly orphaned CMS accounts.
2. Downgrade over-privileged internal roles.
3. Remove hosting or SFTP accounts for former vendors once you confirm they’re no longer in use.
4. Reassign DNS and registrar access to a minimal set of named internal owners.

Make a note of each change and the timestamp.

Step 3: Notify active vendors with simple explanations

For current vendors, communicate early. A short, clear message is enough:

We’re standardizing administrator access across our systems. You’ll continue to have the access you need for current work, but we’re removing legacy paths and shared logins. If you hit any access issues, contact [named internal owner].

This sets expectation that admin access is being governed, not withdrawn randomly, and it gives vendors a path if you misjudge a permission.

Step 4: Eliminate shared generic logins

As you close the loop, prioritize:

• Replacing shared CMS logins with individual accounts
• Moving from shared inbox password resets to personal corporate addresses
• Tightening access to password manager vaults shared beyond current teams

This is where you move from ad-hoc convenience to healthier governance.

Step 5: Document the new baseline

When you’re done, record a simple baseline document:

• Current list of admin paths and key accounts
• Named owner for each path
• The date this baseline was last updated
• Any known exceptions with a short justification

Treat this as living documentation, not a one-off artifact.

---

6. Turn one clean-up into an ongoing access review practice

A single clean-up is an improvement. A lightweight recurring practice is Maintenance Maturity.

In practical terms, that means:

• Cadence: Put a quarterly access review on the calendar, or align it with existing maintenance windows.
• Owner: Assign a named business owner (often marketing or product) with IT or operations as partners.
• Scope: Revisit all admin paths, not just the CMS: hosting, DNS, deployment, third-party tools.

A recurring rhythm shifts you from “we’ll tidy this next time something scary happens” to “we regularly confirm our access matches how we actually work.”

If you want more on how recurring reviews support a mature operating model, the broader Website Support articles act as an expansion on related themes like updates, hosting choices, and vendor coordination.

A simple recurring checklist

Each review cycle, run through:

1. New vendors or tools added? Ensure they have named owners and scoped access.
2. Relationships ended? Remove or downgrade access immediately.
3. Team changes? Disable or adjust access for role changes and departures.
4. Exceptions still valid? Reconfirm any temporary elevated access.
5. Documentation updated? Refresh the baseline with changes.

This doesn’t require a security team; it requires leadership attention and a calendar.

Maintenance Maturity in access governance

Using Maintenance Maturity as a lens, you can roughly see three stages:

• Reactive: No inventory, access changes made in a hurry, surprises during incidents.
• Emerging: Occasional clean-ups driven by specific events (vendor changes, redesigns).
• Embedded: Scheduled, documented reviews with clear ownership and a path into security monitoring when patterns look worrying.

Your goal isn’t perfection; it’s to move one stage up and keep climbing.

---

7. When recurring third-party access issues signal the need for security monitoring

If every review uncovers new surprises, the problem isn’t just old accounts. It’s governance collapse: there is no reliable way to know who can change your site, and no process for catching risky patterns early.

Warning signs we often see at this point:

• You find administrator accounts for people who left years ago.
• Tools appear in your site’s code or tag manager that no one recalls approving.
• Security alerts or hosting notifications go to outdated email lists or ex-employees.
• Logs show activity at odd hours from unknown IPs, but no one owns investigation.

In this state, each new issue becomes a fire drill:

• Incidents take longer to diagnose because no one knows which vendors to call.
• Outages or misconfigurations are harder to untangle due to overlapping access.
• Leadership starts questioning whether the website is truly under control.

At that point, the right question is no longer, “Who should we remove?” but “Who is actively watching and governing this as an ongoing risk?”

From ad-hoc reviews to structured monitoring

A structured monitoring and governance approach typically adds:

• Centralized visibility into admin changes and security events
• Defined thresholds for when to escalate an alert into investigation
• Clear runbooks for who does what when something suspicious appears
• Alignment between technical signals and business impact

Our Website Security & Monitoring work is designed as an operationalization of everything in this article: turning one-time inventories and permission clean-ups into a repeatable practice with eyes on the system, not just on the user list.

If your access review surfaced broader support concerns — like unclear vendor boundaries, inconsistent update patterns, or recurring incident noise — the article on related guidance on what to review before turning website support concerns into a website improvement plan is helpful escalation reading to connect day-to-day friction with structural fixes.

And if you’re simultaneously considering new vendors, it can be useful to contrast this cleanup work with the forward-looking questions in related guidance on what to ask before giving a new vendor website admin access so that new relationships don’t reintroduce the same risks you just removed.

---

Turning your review into a concrete decision

If you’ve read this far, treat it as a decision point, not just a checklist.

Approve, explicitly, that:

• Every admin path will have a named internal owner and a documented business purpose.
• Shared generic logins will be phased out in favor of individual, traceable accounts.
• Access reviews will happen on a recurring cadence, not only after incidents.

If you can’t approve those statements today, that’s the governance gap to surface to leadership.

Leaving third-party admin access unreviewed doesn’t just increase breach risk; it quietly raises the cost and chaos of every outage, migration, and vendor change. When no one is sure who can touch what, each incident becomes slower, more political, and more expensive.

If your latest review surfaced ex-staff logins, opaque tools, or security alerts no one can interpret, it’s a sign you’ve reached the edge of what ad-hoc clean-ups can handle. This is the point to bring in structured support so that monitoring, alert triage, and access governance live in a defined operating model instead of whoever notices the latest email.

To apply this decision to your own website, discuss the next step with our team.