Least-privilege access and offboarding for websites and cloud accounts

A contractor built a nonprofit's donation campaign site two years ago and was given an administrator account to do it. The project ended, the account stayed. When the contractor's own email was later compromised, the attacker used the password reset link to take over the CMS. Nobody at the nonprofit knew the account existed. Old accounts with too much access are among the most common ways into a website, and they are entirely preventable.

What least privilege means

Least privilege means each person and system gets only the access they need for their job, and only for as long as they need it. An editor who updates news stories does not need to install plugins. A developer who deploys code does not need to read the production database. A vendor who fixed one bug does not need an account next year. Every extra permission is something an attacker can use if that account is taken over.

Roles in the CMS

A practical target: no more than two or three people per site with full administrator rights, named, and using multi-factor sign-in. Everyone else gets the narrowest role that lets them do their work. On Drupal, review which roles can use full HTML text formats, since that permission can let someone add script to a page.

Access in the cloud

• No shared logins. Each person signs in as themselves, through single sign-on where possible, so every action is traceable.
• Temporary over permanent. Grant elevated access for a task and let it expire, rather than leaving standing administrator rights.
• Separate production. Day-to-day development work happens outside the production account; production access is limited and logged.
• Machines get roles, not keys. Servers and automated jobs use cloud roles with narrow permissions instead of long-lived access keys pasted into configuration files.
• Review integrations too. API keys and app passwords issued to plugins, form tools, or a CRM connection keep working after the person who created them leaves. List them and rotate or remove them as part of every review.

A 30-minute access review

Run this twice a year, and after any reorganization or vendor change:

1. Export the user list from each CMS, and from the cloud and DNS accounts.
2. Mark anyone who has left, changed roles, or finished a contract.
3. Check every administrator: is the person known, still needed, and using MFA?
4. Look for generic accounts such as "admin," "webmaster," or a vendor's company name, and replace them with named accounts.
5. Look at last sign-in dates. An account unused for 90 days is a candidate for removal.
6. Record what you removed and when. Auditors will ask.

Offboarding the same day

The highest-risk moment is the day someone leaves. With single sign-on, disabling their account in your identity provider removes access to every connected system at once, which is the strongest argument for SSO. Without it, keep a checklist: CMS accounts on each site, cloud consoles, DNS and registrar, shared password vault entries, and any API keys or deploy credentials they created. Reassign content they authored instead of deleting the account where your CMS would delete their content with it.

A note for government agencies

Agencies often operate under policies that require documented access reviews, named accounts, and prompt removal of access for departing staff and contractors. A dated record of each review, and an offboarding checklist that covers every site, turns those requirements into evidence an auditor can check quickly.

How eWay handles access

On environments eWay manages, administrative access requires MFA, standing privilege is kept to a minimum, and every privileged session is logged. There is no inbound SSH from the internet; access goes through SSH keys or AWS Session Manager via a controlled path. Under the shared responsibility model, your organization owns CMS user accounts and roles. eWay can export user and role lists for your reviews and help connect your sites to single sign-on so offboarding happens in one place.

What to include in a support ticket

• The sites and accounts involved
• For removals: the person's name, their accounts, and the date access should end
• For urgent removals after a dismissal or suspected misuse: say so, and assign P2 or higher

eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: multi-factor sign-in and passkeys, setting up single sign-on for Cascade authors, and severity levels and response times.