TrustedLogin vs. sharing your admin password in a password manager

Open your agency’s shared vault and search for a client you stopped invoicing two years ago. The entry is probably still there: the site URL, a username, a password somebody generated during onboarding, and a note reading “WP admin, don’t delete.” Nobody deleted it, because deleting the vault entry doesn’t remove the WordPress account, and removing the account means logging into a live production site that hasn’t been yours to touch since the retainer ended.

The password manager did the job it was built for. The problem is what it was asked to hold: a standing WordPress Administrator password, a credential with no expiry to enforce and no mechanism by which a vault can reach into a site and end it.

The vault entry that outlives the project

Agencies accumulate these one client at a time, and the accumulation is invisible until someone counts. Every site you’ve ever onboarded added an entry. Every contractor who rolled off the account had read access to the folder that holds them, and removing that person from the vault today does nothing about the credentials they copied out of it eighteen months ago. Our own agencies page calls it a vault that has become a liability with a search bar. The credentials in it are searchable and still valid.

The reason nobody cleans it up is that cleanup is not a vault operation. To retire one of those entries properly you have to log into the client’s live site, find the account, and either rotate its password or delete the user, on a site that might be running a checkout, a booking calendar, or an integration that authenticates as that exact account. That’s a change-management task on somebody else’s production system, undertaken for no revenue, to close a risk nobody has complained about yet. It loses to billable work every week, forever.

What a password manager solves, and where it stops

A vault like 1Password is real infrastructure for a real problem. 1Password Business describes itself as a way to “Manage access, securely share passwords, and generate reports – all from one place,” and lists “Audit-ready activity logs” plus Watchtower breach monitoring among what it provides (1password.com/business, retrieved September 1, 2026). Those are genuine capabilities. Role-based sharing means a junior developer can hold the staging credential and not the registrar login. Breach monitoring tells you when a password you’re storing has turned up in a dump. Storing credentials outside WordPress means a compromised site doesn’t hand an attacker your whole client list.

None of that touches the failure above, for structural reasons.

A vault’s activity log records vault events, not site events. It can tell you that an agent opened the entry at 2:12 p.m. It cannot tell you whether anyone logged into the site, what role they used, what they changed, or when they stopped. Once a password leaves the vault it leaves the log’s field of view, and the copy in someone’s clipboard, terminal history, or second password manager is no longer an entry you can revoke.

Revocation, in a vault, is rotation. There is no “stop sharing” switch that reaches WordPress. Deleting the entry removes your copy of a password that still works. To end the access you have to change it on the live site, which is the task nobody performs.

Access that ends without a vault entry

TrustedLogin removes the standing credential from the arrangement, so there is nothing left for a vault to store.

When a client needs help, they click Grant Access inside a product they already have installed, a plugin or theme built with TrustedLogin’s free SDK. Your team gets in without holding anything afterwards: their site creates a new WordPress account, scoped to the role your plugin was configured to request, and encrypts its login secret before anything leaves their server. The role and the access window are settings you chose once when you integrated the SDK, not a menu the client picks from at grant time.

Each of the following maps to a failure above:

• It expires without anyone remembering to end it. The account is deleted on schedule by the client’s own site, on its own cron, so expiry doesn’t depend on TrustedLogin being reachable that day.
• The client can revoke it themselves. It’s an ordinary WordPress user account on their site, so they or their host can remove it directly in wp-admin, with or without us.
• The record is about the site, not the vault. Our security page describes what the audit log holds: which site, which of your support agents logged in, what role they had, when the session started and ended, kept 90 days.

A security-minded client will ask where the decryption key sits, so here it is exactly. The client’s site encrypts using your public key. The private key that decrypts it is a long-term keypair generated and held on your own site, inside the Connector plugin, and never leaves it. TrustedLogin’s servers store and relay ciphertext; nothing decrypts on our infrastructure at any point, and the exchange is drawn out step by step on how it works.

When the engagement ends, there’s no vault entry to clean up, because there was never a standing password to file.

The credentials a password manager should still hold

TrustedLogin removes one credential from your vault: the WordPress login. Everything else stays. The hosting panel, the registrar, the DNS provider, Stripe, the client’s Google Workspace, SFTP, and your own team’s accounts all still need somewhere to live, and a password manager is still the right place.

There’s a second overlap, on the other side of the problem. When you have to hand a client a credential once, whether an API key, a database password, or a license, 1Password and Bitwarden users reach for the built-in sharing tools. 1Password’s item sharing lets you “Choose when the link expires and who it’s available to: anyone with the link or only specific people” (support.1password.com, retrieved September 1, 2026). Bitwarden Send is “a tool to transmit sensitive text or files directly to anyone through secure, temporary links,” with a deletion date, an optional maximum access count, and the statement that “Data is encrypted on creation and only decrypted when a recipient opens the link” (bitwarden.com/help/about-send, retrieved September 1, 2026).

Both are good general-purpose tools, and if you already run one, it works. TrustedLogin’s Connector ships the same idea scoped to the support case it was built for: one-time secrets created by whoever on your team already holds the support capability on your own WordPress site, with no separate product or account to administer. They’re created, encrypted, and stored entirely on your own site, and they never touch TrustedLogin’s servers. Single-view secrets are destroyed on first read; reusable ones live until an expiry you set, up to 30 days. The decryption key lives only in the link’s URL fragment, the part a browser never sends to any server, so your site holds ciphertext and a one-way hash of that key and nothing that opens it. Every secret leaves a record on your own site: created, viewed, from where, kept 90 days.

One difference in the other direction: 1Password and Bitwarden can send files. TrustedLogin’s secrets are text only. If you’re sending a client a .zip, use the tool that sends a .zip.

A standing password against a per-request account

	Shared vault entry	TrustedLogin grant
What’s shared	A standing WordPress Administrator password	Nothing standing; a scoped account is created per request
Who creates it	Whoever set the site up, once	The client’s own site, each time they grant
Expiry	None; valid until someone rotates it	Enforced by the client’s site on its own schedule
How you end it	Log into the live site and rotate or delete the account	It expires on its own; the client can revoke in wp-admin; you can revoke early
What the log tells you	Who opened the vault entry, and when	Which site, which agent, what role, when the session started and ended (kept 90 days)
After the engagement	The entry stays until someone cleans it up	Nothing left behind
Also covers	Every other credential your agency holds	The WordPress login, plus one-time secrets on your own site

An hour’s work you can do this week

Sort your shared vault by date modified, oldest first, and list every WordPress admin entry over twelve months old. For each one, the decision is three ways: still an active client, rotate now, or delete the account entirely. Expect the third bucket to be the largest, and the one nobody had a reason to open.

Then, for the clients that stay, ask which of their installed plugins and themes is built on the TrustedLogin SDK. That answer decides whether the next engagement adds another line to the vault or doesn’t need one. If you’re weighing this against the free single-site option, the Temporary Login Without Password comparison sets the two side by side, and pricing starts at a free tier for evaluation.

The entry from two years ago is what happens when the credential you’re handed has no end date and the tool holding it was never given a way to enforce one.