Admin access and passwords: a practical policy for...

When security incidents happen in small organizations, they often start with something boring: an old account that never got removed, a shared admin login that “everyone knows,” a weak password that gets reused, or a missed MFA prompt that looked legitimate. The good news is that you do not need enterprise complexity to reduce this risk. You need a practical policy that your team can actually follow.

This post lays out a simple, workable approach to admin access and passwords for small teams. It focuses on access control, shared accounts, MFA, and role separation, plus the operational habits that keep it consistent over time.

What you are trying to achieve (in plain language)

A good access policy aims for four outcomes:

Accountability: you can tell who did what, and when.
Least privilege: people have only the access they need for their role.
Resilience: one mistake does not become a full compromise.
Continuity: access changes are predictable during onboarding, role changes, and offboarding.

Small teams often default to “whatever is fastest today.” The policy below is designed to keep work moving while cutting out the most common failure points.

Start with roles, not people

The easiest way to keep access clean is to define roles first, then assign people to roles. Even a team of three can benefit from basic role separation.

A simple role model that works for many small teams

Owner / Executive: needs visibility and approvals, not daily admin access.
Operations / Admin: handles invoicing, HR, documents, and shared tools.
Website / IT Admin: manages platforms like WordPress, hosting, DNS, and SaaS admin consoles.
Staff / Contributors: uses line-of-business tools without admin privileges.
Vendors / Contractors: time-limited access to a narrow set of systems.

In practice, one person may wear multiple hats. That is fine. The key is that they do not use the same account for every hat.

Two-account rule for anyone with admin privileges

If someone needs admin rights, they should have two accounts:

Daily account: email, documents, chat, project tools. No global admin rights.
Admin account: used only for privileged actions (billing, user management, security settings, DNS, hosting, WordPress admin tasks).

This reduces the damage from common threats like phishing. If the daily account is compromised, the attacker still has hurdles before they can change core systems.

Shared accounts: when they exist, make them controlled exceptions

Shared accounts are popular because they feel convenient. They are also one of the fastest ways to lose accountability and make incidents harder to investigate.

As a baseline, prefer:

Individual user accounts for every person.
Shared mailboxes, shared calendars, and shared documents instead of shared logins.
Role-based access inside tools (for example: “Editor” vs “Administrator” in a CMS).

Legitimate reasons a shared account might be unavoidable

Sometimes a shared account is genuinely hard to avoid, such as:

A front desk login on a kiosk device.
A legacy vendor system that does not support multiple users.
A single hardware control system that only supports one credential.

If you must use a shared account, treat it like a controlled exception and do three things:

Store it in a password manager with restricted access, not in a note or email thread.
Rotate it on a schedule and immediately after staff or vendor changes.
Wrap it with compensating controls: limit where it can be used (specific device or IP if possible), require MFA if supported, and keep logs where available.

If your team is using shared WordPress admin logins today, consider moving to individual WordPress accounts with the minimum roles needed. If you want help setting up a cleaner access model for WordPress and site administration, managed maintenance and security support can also include tightening account controls as part of ongoing technical management.

Passwords: focus on storage and uniqueness, not memorization

Many password policies fail because they ask people to do something unrealistic: memorize dozens of complex passwords and never reuse them. The more realistic approach is:

Use a password manager as the standard way to create, store, and share credentials.
Require unique passwords for every system, especially email, hosting, domain registrar, banking, and admin consoles.
Use long passphrases when a password must be typed manually (for example on a phone or in a kiosk scenario).

Minimum password standards that are easy to enforce

Unique per system: no reuse between email, hosting, WordPress, registrars, accounting, or CRM tools.
Long by default: password manager generates long random passwords for saved credentials.
Passphrases for manual entry: a memorable phrase that is still long and unique.
No sharing in chat or email: credentials are shared only through the password manager’s sharing feature.

In many teams, the single biggest improvement is simply moving “where passwords live” from informal places (notes, spreadsheets, email drafts) into a password manager with access controls and auditing.

What to do about “we need a common login for the team”

If the real need is “multiple people need to access the same resource,” the answer is usually not a shared password. It is one of these alternatives:

Shared mailbox: for example, billing@ or info@ managed as a shared mailbox with individual access.
Shared folder with permissions: one repository, different permissions by role.
Delegated access: where a tool allows assistant or delegate roles.
Service account: used only by a system integration, not by humans, and stored/managed like an exception.

MFA: make it standard, and prioritize phishing-resistant options

MFA should be required on anything that can change money, identities, or infrastructure. At a minimum, that includes:

Email accounts and the admin console for email services
Password manager accounts
Domain registrar and DNS provider
Hosting control panels and cloud provider consoles
WordPress administrator accounts
Accounting and payroll systems

Which MFA methods to prefer

Not all MFA is equal. A practical preference order for many organizations is:

Passkeys or FIDO2 security keys: strong protection against common phishing attacks.
Authenticator app: time-based codes or push prompts, ideally with number matching if offered.
SMS: better than no MFA, but generally weaker than the options above.

If your team has had repeated phishing attempts or you manage sensitive programs or personal data, consider moving key admin accounts to phishing-resistant MFA (passkeys or security keys) first.

Make MFA survivable: recovery and backup methods

MFA fails in real life when the only person with access loses a phone or changes devices and no one planned for recovery. Your policy should define:

Who can reset MFA for a user account (and how identity is verified internally).
Backup methods(for example: a second security key stored securely, or verified recovery codes stored in the password manager).
“Break glass” access for emergencies (covered below).

Admin access: define what “admin” means in your environment

“Admin” is not one thing. Most small organizations have multiple admin surfaces, and each has different risk:

Email admin: can reset passwords and intercept communications.
Domain registrar and DNS: can redirect web and email traffic.
Hosting admin: can access files, databases, backups, and server settings.
WordPress admin: can install plugins, change themes, create new admins.
SaaS admin (accounting, CRM): can change billing and export data.

One practical approach is to create an “Admin Systems List” with the system name, who has admin rights, where MFA is configured, and where credentials are stored. Keep it short and current.

Least privilege in WordPress and website operations

For WordPress specifically, role separation can reduce risk without slowing publishing:

Authors and editors publish content without administrative privileges.
Admins are limited to the people who manage plugins, themes, updates, and user management.
Plugin/theme installs are treated as a controlled activity, not an everyday habit.

If your organization relies on a website for public information, programs, or service delivery, it is also worth defining who is responsible for updates and security monitoring. For teams that prefer not to manage this internally, ongoing WordPress maintenance and security management can formalize those responsibilities while keeping changes predictable.

For First Nations organizations and other community-focused organizations, access control is also a governance issue: it helps ensure that updates to public program information, leadership communications, and community resources are made by the right people with clear approval paths, and that imagery and content permissions are respected and documented.

Break-glass accounts: emergency access without daily risk

A break-glass account is an emergency account used only when normal admin access is unavailable (for example: an admin is locked out, MFA fails, or a provider outage blocks standard login flows).

A practical break-glass policy includes:

One or two dedicated emergency accounts for the most critical systems (email admin, registrar, hosting).
Strong authentication with phishing-resistant MFA where possible.
Credentials stored securely(password manager with restricted access, or a sealed offline method if required by governance).
Documented rules for when it can be used and who must be notified.
Periodic testing to confirm it still works.

The goal is to avoid the common anti-pattern where the “emergency account” becomes the everyday shared admin login.

Onboarding and offboarding: the part that prevents the most pain

Most access problems happen when someone joins or leaves and the organization improvises. The fix is a checklist that is followed every time.

Onboarding checklist (minimum viable)

Create an individual user account for each required system.
Assign roles, not blanket admin rights.
Enroll MFA on day one for email, password manager, and any admin consoles.
Add the person to shared resources (mailbox, folders, tools) rather than sharing passwords.
Confirm the password manager is installed and working.

Offboarding checklist (minimum viable)

Disable the user’s accounts first, then review and remove access across systems.
Transfer ownership of shared assets (domains, ad accounts, analytics, key documents).
Rotate any shared credentials the person could access (or, better, eliminate those shared credentials).
Review admin role assignments and remove unnecessary privileges.
Check forwarding rules and mailbox delegates in email systems.

If you only adopt one formal process, make it offboarding. It is the moment where “old access” quietly becomes a long-term risk.

Vendors and contractors: time-box access and keep it narrow

Small organizations rely on vendors for bookkeeping, IT, web development, marketing platforms, and more. Vendor access is often granted quickly and removed slowly, if at all.

A practical vendor access policy:

Use named accounts whenever possible, not a shared “vendor” login.
Time-box access with a review date (for example: 30 or 90 days).
Grant the minimum needed access and remove it when the task ends.
Require MFA for vendor accounts that touch admin surfaces.
Log what matters(admin actions, permission changes, plugin installs, DNS changes) where your platforms support it.

If a vendor insists on using your shared admin credentials, treat that as a risk signal. A better standard is to provide a dedicated account with the right permissions and revoke it later.

Logging and review: keep it lightweight but consistent

You do not need a full security operations centre to benefit from review habits. Pick a cadence that matches your size.

A monthly 15-minute review that catches a lot

Review who has admin access in your core systems.
Check for unused accounts and disable them.
Confirm MFA is still enabled for admins.
Review recent admin activity where available (permission changes, DNS edits, plugin installs).

If you run a WordPress site, it is also worth reviewing what changed recently: updates, new plugins, new users, and any unexpected redirects or content edits.

A short policy you can copy into your internal docs

If you want something you can paste into an internal handbook, here is a compact policy statement you can adapt:

All staff and vendors use individual accounts. Shared logins are exceptions only.
Anyone with admin rights uses a separate admin account from their daily account.
MFA is required for email, password manager, domains/DNS, hosting, and all admin consoles.
Credentials are stored and shared only through the approved password manager.
Admin access is granted by role and reviewed monthly.
Onboarding and offboarding checklists are required and must be completed for every person.
Vendor access is time-boxed, least privilege, and removed when work ends.

That is enough for many small organizations to reduce common risks without turning work into a constant approval process.

Where this fits with your website operations

Websites are often part of the “infrastructure layer” without being treated that way. If your organization depends on its website for credibility, lead flow, community information, or online services, then access to WordPress, hosting, and domain/DNS should be managed with the same care as email and finance tools.

If you want to talk through your situation, contact ALPHA^+V3 to discuss practical options that fit your team and your systems.

Sources

Category: Website Security

Admin access and passwords: a practical policy for small teams