When a dashboard has no user management

Practical guides · About 6 minutes

Every guide about access control assumes the vendor gives you users and roles. Plenty don't. The regional payment gateway, the industry-specific portal, the small tool that does one thing well, the government filing site — one login, no roles, no audit log, and a support team who don't understand the question. This is about working sensibly inside that constraint instead of pretending it isn't there.

First, confirm it's actually true

Before designing around the limitation, spend ten minutes verifying it exists. It's wrong more often than you'd think:

• The feature may be on a higher plan. Annoying, but a plan upgrade is usually cheaper than the ongoing cost of a shared credential, and much cheaper than one incident.
• It may be hidden. User management turns up under "Team", "Organisation", "Company profile", "Sub-accounts", "Delegated access", or buried in billing settings. It isn't always where you'd look.
• It may have shipped since you checked. Products grow. If your judgement is more than a year old, re-check.
• There may be a different access model entirely. Advertising, analytics, and merchant platforms often use partner or agency linking rather than user seats — a completely separate menu, and exactly what you want if you manage accounts on someone's behalf.
• Ask support directly. "How do I give a colleague access without sharing my password?" Their answer is worth having on record either way.

If you land on a genuine no, you now have a documented exception rather than an assumption. That distinction matters for everything that follows.

Reduce how many people need it

The cheapest control is fewer holders. Before improving how you share a credential, question whether it needs sharing at all.

Often the reason several people have access is that each needs one small thing — a monthly figure, an invoice, a status check. If one person can produce that output on a schedule, or the data can be exported to a place others already have access to, the number of people needing the login drops to one or two.

This isn't gatekeeping for its own sake. With no audit log, every additional holder is a permanent, unattributable increase in risk that you cannot undo except by rotating. Reducing the count is the only lever that works cleanly.

Compensating controls

You can't get attribution or roles, but you can make the credential harder to misuse and easier to clean up.

Store it as a deliberate exception

A dedicated shared collection in your password manager — not someone's personal vault — with the smallest possible group, and a note in the entry saying why it's shared and when you last checked for alternatives. That note is what stops a temporary workaround becoming permanent by default. Re-check at renewal, when you have leverage.

Put the second factor with the credential

If the service supports 2FA, enable it and store the TOTP seed in the same shared vault entry. The factor stops being "something only you have" — but it still defeats a stolen-password attack, which is the realistic threat. What you must avoid is routing the factor through one person's phone, which produces codes relayed over chat and, eventually, someone disabling 2FA to get work done. The 2FA guide covers this pattern in more detail.

Use a role address, not a person's

Register the account to billing@ or ops@ rather than an individual's address. Then password resets, security alerts, and vendor notices land somewhere the team controls, and the account doesn't quietly become unrecoverable when that person leaves. Retrofitting this is usually a simple email change in settings, and it's the highest-value fix on this list.

Get attribution outside the system

Since the platform won't tell you who did what, capture it yourself where the actions matter — a shared log of significant changes, or a rule that anything irreversible gets announced in a team channel first. Lightweight and imperfect, but it turns "nobody knows" into "we can reconstruct it", and it's the only form of attribution available to you.

Constrain what the account can reach

Where the vendor offers IP allowlisting, use it. Where the sensitive actions are the ones that move money or change payout details, check whether those specific operations can be locked behind a separate confirmation the vendor does support — some products with no user management still have a distinct "authorised contact" for financial changes.

Rotate on every departure, without exception

This is the one that gets skipped, and it's the only real revocation you have. When someone with access leaves, the credential changes. Your vault should be able to tell you which entries that covers — which is the entire reason for keeping them in a dedicated collection.

Pressure the vendor, properly

Vendors add user management when customers ask in a way that reaches the roadmap. A support ticket that says "please add roles" goes nowhere. One that says "we have four people needing access; the absence of user accounts is a compliance blocker for us at renewal" gets escalated, because it's attached to revenue.

Ask at renewal rather than mid-contract. Ask in writing. Ask for a timeline, and if there is one, note it in your inventory with a date to re-check. If enough of a vendor's customers do this, the feature ships — and even when it doesn't, you now have a documented reason to consider alternatives.

Know when to walk

Sometimes the right answer is to replace the tool. It's a real cost, so weigh it honestly. Reasons that justify migrating:

• The account controls money movement, and you cannot attribute actions to a person.
• It holds customer personal data and you have obligations about who accessed it.
• Your team is growing, so the number of people needing the shared login keeps rising.
• A competent alternative exists at comparable cost with proper access control.
• You've asked twice, across two renewals, and there's no roadmap.

Reasons that don't, on their own: it's mildly annoying; a competitor's marketing page looks better; you'd prefer nicer UX. Migration has real costs — data export, retraining, integration rework, the period where both systems run. Make the decision on risk, not aesthetics.

Track them as a set

Add a column to your inventory marking which services lack user management. That column turns a scattered irritation into a list you can act on: it tells you exactly which credentials to rotate at every departure, which vendors to push at renewal, and — when someone asks how exposed you are — gives you an answer instead of a shrug.

It also shrinks over time, which is quietly satisfying. Vendors ship the feature, you migrate off the worst offenders, and the list of exceptions gets shorter. That only happens if the list exists.