Why a website login inventory is different from “password hygiene”
Your site can look fine on Monday and still be someone else’s to break on Tuesday—if you do not know every account that can change it. Registrar logins, DNS panels, hosting dashboards, CMS admins, CDN keys, form handlers, analytics, Search Console, payment widgets, chat tools, and marketing pixels all sit on different platforms with different owners. When those seats stay in personal emails, old vendor accounts, or shared passwords in a chat thread, offboarding a person does not offboard your website.
This is a practical inventory TwoQM recommends for small-business operators: list every control surface that can alter your public site or the systems behind it, record who owns each seat, confirm recovery email and 2FA, and note what happens when someone leaves. It is not a MFA setup guide, a vendor offboarding checklist, or a Google Business Profile audit—those cover different surfaces. This one is the map of website-affecting logins.
Password managers help you store secrets. An inventory tells you which secrets matter for the site and who is allowed to use them. A strong password on a registrar account you never documented still leaves you stranded when the only person who knew the recovery phone moves away.
Treat website access like production equipment: named seats, company-controlled ownership where possible, recovery paths you can prove, and a written offboarding note for every high-impact login.
Step 1: List every system that can change the site
Start a simple sheet with one row per system:
Domain registrar — Who can transfer the domain, change contacts, or renew.
DNS host — Often the registrar, sometimes a separate DNS provider; who can edit A/CNAME/MX/TXT records.
Web hosting / server panel — cPanel, Plesk, cloud console, or managed WordPress dashboard.
CMS / site builder admins — WordPress users, Webflow workspace, Squarespace owner, Shopify staff.
CDN / WAF / edge — Tools that can cache, block, or rewrite traffic.
Form and email handlers — Contact forms, SMTP plugins, transactional email (SendGrid, Mailgun, Postmark).
Analytics and Search Console — GA4 property access, Google Search Console owners/users.
Payment and booking widgets — Stripe, Square, Calendly, or embedded checkout accounts on the site.
Chat, CRM embeds, and marketing pixels — Live chat admin, CRM site tracking, Meta/Google ads pixels with publish rights.
If a tool can change what visitors see, form email, or domain verification in search tools, it belongs on the list.
Step 2: For each seat, capture owner, recovery, and 2FA
Columns that actually help later:
System + URL — Exact login page, not “the host.”
Account email / username — Prefer company addresses over personal Gmail when the vendor allows it.
Role — Owner, Admin, Editor, Billing-only (write what the product shows).
Human owner — Named person on your team, not “the agency.”
Recovery email and phone — Confirmed current this quarter.
2FA status — On / off / app vs SMS / where backup codes live.
Vendor / contractor? — Yes/no, and contract end date if known.
Offboarding note — Who removes access, and what replaces it (transfer Owner first).
Last verified — Date you signed in or confirmed the roster.
You need a list you can walk in under an hour next time someone leaves—not perfect history on day one.
Step 3: Flag “single point of failure” seats
Highlight any row where:
Only one person can sign in, and they use a personal email.
2FA is off, or recovery phone is a departed employee’s cell.
A former vendor still holds Owner while your team only has Editor.
DNS and hosting live under different logins nobody documented.
Those are the seats to fix before you need an emergency transfer. Fix order for most shops: registrar + DNS ownership, then hosting/CMS Owner, then edge/CDN, then the long tail of pixels and widgets.
Step 4: Separate “can publish content” from “can break DNS”
Not every seat deserves the same panic level. Rough tiers:
Tier A (site goes dark or moves): registrar, DNS, hosting root, CDN zone admin, primary CMS Owner.
Tier B (site lies or leaks leads): form/SMTP handlers, payment widgets, chat that can misroute customers.
Tier C (measurement and ads): analytics, Search Console, pixels—important, but usually not an overnight outage.
Document who may grant new Tier A seats. Usually that is an owner-operator or ops lead—not every marketer with CMS Editor access.
Step 5: Tie the inventory to hiring and vendor changes
When you hire a web vendor or seasonal marketer: grant the minimum role that gets the work done; put an end date on the inventory row the same day; prefer named invites over shared passwords; on contract end (or staff last day), remove seats the same day you revoke email—and confirm Tier A Owners on your side can still sign in first.
When you change hosts or rebuild the site, update the inventory in the same window. A new CMS with DNS still under an abandoned registrar login is not a finished migration.
A quarterly 20-minute check
Once a quarter is enough for many small teams; monthly if turnover is high:
Open the sheet—any system missing (new chat tool, new form plugin)?
Spot-check Tier A: can your Owner accounts still sign in?
Confirm recovery contacts on registrar and hosting.
Remove anyone who no longer needs access.
Log the check date.
This pairs with—not replaces—MFA on hosting/domain/email, vendor offboarding, and backup drills. Those assume you already know which doors exist.
When to get help
Get help when Owner seats sit under an unreachable personal account, a registrar lock fights a domain move, or three vendors each believe they “own” DNS. TwoQM’s bias: one living inventory, company-controlled Tier A Owners, short-lived contractor grants, and recovery paths you have tested—so the website stays yours after people and tools change.
Build the inventory this week. The next surprise login should be one you already expected.