How to manage logins for 20+ admin dashboards without losing track

Practical guides · About 7 minutes

The problem creeps up on you. You start with a CMS and a mail provider. Two years later there's a payment processor, three ad platforms, a DNS registrar, two analytics tools, a helpdesk, a status page, a CI provider, and four client dashboards you inherited from someone who left. Nobody decided to build this; it accumulated. This guide is about getting back in front of it.

Start with an inventory, not a password manager

The instinct is to open a password manager and start typing. Skip that for an hour. The reason people lose control of dozens of accounts isn't bad storage — it's that no single list of the accounts exists anywhere. You cannot rotate, audit, or hand over what you haven't written down.

Open a spreadsheet and give it one row per login, not per service. If you have two accounts on the same ad platform for two different clients, that's two rows. Columns worth having from day one:

• Service — the product name.
• Login URL — the exact page, not the marketing homepage. Many services have a separate admin. or app. host, and some have a completely different URL for SSO logins.
• Identity — which email or username signs in. This is the column people most often can't fill in from memory, and it's the one that causes the most wasted time later.
• Auth method — password, Google/social sign-in, SSO, or magic link. These behave very differently and it matters enormously for the rest of this guide.
• Second factor — none, SMS, TOTP app, hardware key. Note where the factor lives, not just that it exists.
• Who else has access — even if the answer is "just me", write it.
• What it can do — one short phrase. "Can issue refunds." "Can change DNS." "Read-only reporting."

That last column is the one that turns a list into a plan. Expect the inventory to take longer than you think and to surface at least one account nobody remembered was still active. That discovery alone usually justifies the exercise.

Rank by blast radius, not by how often you log in

Not all of these accounts deserve the same treatment. The useful axis is blast radius: if someone else got into this account tonight, how bad would tomorrow be, and could you undo it?

A rough three-tier split works for most people:

The point of the ranking is that it lets you spend your limited patience where it pays off. Hardening twelve Tier 3 reporting dashboards while your domain registrar still uses SMS codes is effort spent in the wrong place.

Match the storage to the tier

Once accounts are ranked, storage stops being a single decision and becomes three.

Tier 1 should be the smallest, most deliberate set. Long unique passwords, a hardware key or a TOTP app rather than SMS, and — critically — recovery details you have actually tested. Do not store a Tier 1 second factor on the same device that holds the Tier 1 password if you can avoid it. These accounts are logged into rarely enough that a little friction costs you almost nothing.

Tier 2 wants strong storage plus an access trail. If more than one person touches these, prefer the service's own user management over a shared login, so that actions are attributable to a person. We cover that in detail in the guide on sharing access without sharing passwords.

Tier 3 is where volume lives, and where automation earns its keep. These are the accounts you open every morning, and the ones where friction actually changes behaviour: if logging in is tedious, people start reusing passwords, staying signed in on shared machines, or writing credentials somewhere convenient and terrible.

Fix the naming before it becomes archaeology

Twenty entries called "Dashboard", "Dashboard 2", and "client login (new)" are a slow-motion disaster. Pick one naming scheme and apply it to everything, including the entries you already have.

A scheme that survives contact with reality looks like Service — Account — Role:

• Stripe — Northwind — admin
• Stripe — Northwind — read-only
• Cloudflare — personal — DNS

Consistent, front-loaded names sort usefully, search predictably, and — the real payoff — make it obvious when you're about to log in with the wrong identity. Most "why can't I see the setting?" support tickets are actually "you're signed in as the wrong account".

Session lifetime is the variable nobody accounts for

Here's the thing that makes multi-dashboard work uniquely annoying, and it isn't the passwords. Every service picks its own session length, and they range from a few hours to essentially forever. Financial and infrastructure tools tend to expire aggressively. Marketing and analytics tools often keep you signed in for weeks.

The practical consequence: you are never logged out of everything at once and you are never logged into everything at once. You're perpetually in a partial state, so every task starts with an unpredictable amount of re-authentication. That unpredictability, more than the total number of logins, is what makes the work feel heavy.

Two things help. First, note the rough session length in your inventory once you learn it — it turns a surprise into a schedule. Second, stop treating logins as interruptions to be handled one at a time and start treating them as a batch.

Turn the grind into a routine

Group your dashboards by when you actually need them rather than by what they are:

• Every morning — the three or four you genuinely check daily.
• Weekly reporting — the set you only open to pull numbers on a fixed day.
• Per client or per project — the cluster you need together, or not at all.
• Rarely — the registrar, the billing portal. Deliberately high-friction, and that's correct.

Then open each group as a group. Doing all of one cluster's logins in a single pass costs far less attention than scattering them across the day, because you pay the context-switching cost once. This is exactly the pattern mySwitchBoard automates — each site in a selected group opens as its own real browser tab and signs itself in, in sequence — but the grouping habit is worth adopting regardless of what tool you use.

Plan for the day it goes wrong

An inventory is also a recovery document, and it's worth spending twenty minutes making it one. For your Tier 1 accounts specifically, confirm you can answer these without guessing:

• Which mailbox receives the password-reset email — and is that mailbox itself Tier 1 protected?
• Where are the backup codes, and have you ever verified one works?
• If your phone vanished right now, could you get into the registrar and the primary mailbox?
• Is there a recovery phone number attached that you no longer control?

The circular dependency in the first question catches a startling number of people: the account that recovers everything else is protected by a factor stored only on the device you just lost. Break that loop before you need it.

A short checklist

1. List every login, one row each, including the identity used.
2. Tag each row Tier 1, 2, or 3 by blast radius.
3. Harden Tier 1 completely before touching anything else.
4. Rename everything to one consistent scheme.
5. Note session lifetimes as you learn them.
6. Group the rest by when you use them, and log in by group.
7. Verify the recovery path for each Tier 1 account, then diarise a yearly re-check.

None of this is exotic. It's mostly the discipline of writing things down before the list gets long enough to be intimidating — which, if you're reading this, it probably already has.