Temporary Login Without Password vs. TrustedLogin: your own site or your customers’ sites
A customer emails your support inbox with a bug you can’t reproduce from a screenshot. You need to be inside their site. Temporary Login Without Password will get you there: the customer installs it, generates a link, and pastes that link into their next reply.
Look at who did the work. Temporary Login Without Password is a plugin the site’s own administrator installs, on a site they run, so they can hand a login to somebody else. When that administrator is you, on your own site, the whole exchange happens on one screen. When it’s your customer, you have asked someone who didn’t want a new plugin to install one, choose a role, choose an expiry, and email you a URL that logs in whoever opens it.
That’s the line between these two tools: whose site it is, and who has to act to let you in. This compares them on that basis: who administers the site, who logs in, how access is approved, how it ends, and what gets recorded.
Temporary Login Without Password is for a site you administer yourself
Temporary Login Without Password is free, has been on WordPress.org since 2016, and runs on more than 100,000 sites. It generates a link that logs whoever clicks it straight into a WordPress account, no username or password required. You pick the role, including Administrator, and an expiry: an hour, a day, a week, a month, a custom date, or (with a filter) a custom number of minutes. Free-tier logging shows last-login time and access count; a paid Pro tier adds a full activity log and a cap on the link’s total number of uses, per WPBeginner’s walkthrough and the plugin’s own listing.
Where it fits follows from where it runs. The plugin has to be installed on the site being logged into, by somebody who can already install plugins there. On a site you administer, that’s you: you generate the link and send it to the contractor or the developer you want in for the afternoon. The link is the credential, so whoever ends up holding the URL is logged in. On your own site, you chose who that was.
On a customer’s site, you’re not the person who can install it
Two things change when the site belongs to a customer. You can’t set the plugin up yourself, so the customer has to, which turns your first reply into installation instructions for a plugin they didn’t ask for. And the link that logs anyone in now travels through a ticket thread, where it can be forwarded or left open in a shared inbox tab.
The log follows the link rather than the person. WordPress sees one temporary account, so when three of your support staff use it across a week, the plugin records a count of sessions with no way to say which of them was on the site.
TrustedLogin is for the sites your customers administer
TrustedLogin starts where that leaves off: the person who needs to get in doesn’t administer the site and can’t install anything on it, so the request has to travel through software the customer already runs. That software is your plugin.
The Grant Access button comes from TrustedLogin’s free SDK, the code your developer adds to your own plugin, so it appears in your product’s settings screen instead of arriving as a second plugin the customer has never heard of. The customer clicks it, and their site creates a WordPress account at the role your plugin was configured to request, expiring on the schedule you set once when you installed the SDK rather than choosing per request. What travels to your agent is an encrypted site access key rather than a link or a password. TrustedLogin can’t read the key it’s relaying, so no working login is ever sitting with a third party, and only your agent, signed into their own TrustedLogin account, can open it; the full exchange is written out at how it works.
GravityKit’s documentation draws the same distinction: a temporary-login link “automatically logs anyone in who has the link,” where a TrustedLogin key “requires the support user to be logged into the website with the correct permissions.” The agent has to be who they say they are before the key opens anything.
Everything else follows from that:
- The account belongs to the customer – it appears in their own Users screen at the role you configured, and they can revoke it there without asking you.
- The login belongs to a named agent – your agent opens the site from the TrustedLogin dashboard, or from inside the Help Scout or FreeScout ticket they’re already reading, signed in as themselves.
- The grant doesn’t depend on us – the customer’s site expires the account on its own schedule, so a grant already issued keeps working, and stops on time, whether or not TrustedLogin is reachable.
- The button is already on the site – it ships inside the plugin the customer installed for its own reasons, so there’s nothing new for them to install.
Your own site on one side, your customers’ sites on the other
| Temporary Login Without Password | TrustedLogin | |
|---|---|---|
| Who administers the site | You do | Your customer does |
| Who logs in | Whoever opens the link | A named agent, signed into their own TrustedLogin account |
| How access is approved | You approve it by generating the link | The customer clicks Grant Access inside the plugin they already run |
| How it ends | At the expiry you picked, or you delete the account | At the expiry your SDK configuration requests, or the customer revokes it from their Users screen |
| What gets recorded | Free: last login and an access count. Pro: a full activity log | Every login, against the agent who made it |
| Where it lives | On the site being logged into, installed there site by site | In your own product, on every install that already has your plugin |
| Cost | Free (Pro tier for the activity log and a cap on link uses) | Support $49/mo · Growth $99/mo · Scale $249/mo · Enterprise from $499/mo |
Start from whose site it is
If the site is yours and one person needs to be in it for one job, install Temporary Login Without Password and generate the link. That is the correctly sized tool for that job.
If the site belongs to a customer, no link you generate helps, because there’s nothing of yours on their site to generate it with. The access has to be something they grant from inside a plugin they already run, scoped to a role you chose in advance, on a clock, with your agent’s name on it. Ticket volume only sets what getting that wrong costs you: once a month you’d absorb it, and across a customer base it decides whether “who was in my site last month” is answered from a list or from memory.