Temporary admin access for WordPress: the right way to grant it

You have already decided that somebody needs to get into a WordPress site they don’t own, whether that’s a developer reproducing a bug or a support agent looking at a settings screen a screenshot won’t resolve. The open question is what they get, for how long, and what ends it.

Four mechanisms are in common use, and picking the wrong one leaves a standing key behind instead of access that ends. Each is measured below against the same criteria, and the choice turns on whose site it is: your own, where you can install whatever you like, or a customer’s, where the only software you control is the plugin they already run. On a site you administer yourself, the free option covers it.

The five things temporary access has to do

Strip away the tooling and a temporary grant is a promise with five parts:

1. Disclosed before it happens. The site owner sees what is being requested and agrees to it while the credential still doesn’t exist, rather than learning about it afterward from a changelog.
2. Scoped to a role. The grant carries the capabilities the job needs. Reading a form’s settings is not the same permission as installing plugins.
3. Time-boxed on its own. The access ends by itself, on a clock nobody has to watch. “We’ll delete it when we’re done” still depends on somebody remembering.
4. Revocable by whoever granted it. The site owner can end it early, from their own site, without filing a request with anybody.
5. On the record afterward. Somewhere there’s an answer to “who was in here, and when” that isn’t a login count.

Most tools get two or three of these. TrustedLogin is scored against them below on the same terms as everything else.

Method 1: hand-build an Administrator account

This is still the most widely published advice, including from plugin vendors themselves. Formidable Forms’ support documentation walks customers through it: go to Users, then Add New, enter the username formidableforms and the email [email protected], set the role to Administrator, generate a strong password, check Send User Notification, and click Add New User. Delete the account afterward by hovering the row in Users, then All Users, and clicking Delete.

It works. Every WordPress site can do it with no plugin and no third-party service.

Against the five: disclosure is real, since the site owner is the one clicking the buttons. Scoping is possible but the instruction says Administrator. There is no expiry at all, and deletion is a chore somebody has to remember. Revocation is manual. The record is whatever your host’s login log happens to keep.

Method 2: an Application Password

Application Passwords have been in WordPress core since version 5.6, December 2020. Each one is generated from your profile under Users, displayed once, and revocable on its own without touching the account’s real password. WordPress records a Last Used date and IP for each; its integration guide notes the column “is accurate to within 24 hours.”

They are built for machines, not people. An Application Password authenticates REST API requests; it does not log a human into wp-admin. It also carries whatever capabilities the underlying account holds, which for a site owner means the whole site, and core requires no consent screen before one is created: whether a user is asked is entirely the choice of whichever plugin does the asking.

That last gap produced the most-discussed WordPress support-access failure of 2026. Search Engine Journal reported on August 30 that Rank Math’s plugin, running “on over 4 million sites,” created a credential as soon as an administrator opened its Help & Support screen: “The password shows up on your profile as ‘WAP – Rank Math Support Agent.'” The report continues: “This Application Password does not expire. You cannot turn the ‘Support Agent’ off.” Core permits every part of that outcome without requiring any of it.

Against the five: no disclosure unless the developer builds it, no scoping below the account’s role, no expiry, revocable only from a screen most site owners have never opened, and a usage record that rounds to a day.

Method 3: a temporary-login plugin

Temporary Login Without Password, by StoreApps, is on 100,000+ active installs and is the incumbent answer to this whole question. Its own description: it “lets you create a self-expiring login link and share it with a developer, support agent, or guest editor — instead of handing over your username and password.” You can “Assign any WordPress role to a temporary account” and “Set expiry by time (hour, day, week, month) or a custom date,” deactivate an account to cut access immediately, or delete it outright.

That is four of the five, from a free plugin. InstaWP’s Temporary Login (20,000+ installs) does a narrower version of the same thing: a URL that expires on a fixed schedule, revocable by hand, with no role selection or audit log described on its product page.

The tradeoff is in the sentence StoreApps uses as a selling point: “The person just clicks the link and they’re logged in.” The link is the credential. Nothing between generating it and using it establishes that the person clicking is the person you meant to let in, so a forwarded URL, a synced help-desk thread, or a screenshot in Slack is a working login. The other constraint is whose site it is. The plugin lives on the site being logged into, so only somebody who can already install plugins there can set it up. On your own site that is you; on a customer’s site it is the customer, who has to install a plugin they did not ask for before you can get in.

The four methods against those five

	Hand-made admin account	Application Password	Temporary Login Without Password	TrustedLogin
Disclosed before it exists	Yes: the owner creates it	Only if the developer builds a prompt	Yes: the owner creates it	Yes: the owner clicks Grant Access
Scoped to a role	Possible; the common instruction says Administrator	No: carries the account’s full role	Yes: any WordPress role	Yes: the role the vendor configured
Ends on its own	No	No	Yes: hour, day, week, month, or a date	Yes: the site’s own cron deletes the account
Owner can revoke early	Delete the user	Revoke in your profile under Users	Deactivate or delete	Revoke Access in their own Users list and toolbar
Record of who used it	Host login logs, if any	Last Used date, within 24 hours	Whatever the plugin logs, on that one site	Who, which site, what role, when: across every site, kept 90 days
Who sets it up	The site’s own administrator	The site’s own administrator	The site’s own administrator, after installing it there	Nobody new: it ships in the vendor’s plugin
Cost	Free	Free	Free	Free tier for evaluation; paid from $49/mo

TrustedLogin is for the sites your customers administer

Start with the sites it isn’t for. If the site is one you administer yourself, install Temporary Login Without Password on it and stop reading. It’s free and it does four of the five. The head-to-head between the two is written out here.

TrustedLogin is built for the other case: a support team whose people have to be inside sites their customers administer, where they have no way to install or configure anything themselves. That changes the question from “how do I grant access” to “how does a customer grant access from software they already run, and how do I see all of it in one place.”

The customer’s site creates the account and deletes it

Your customer never installs anything or trusts a second company; the request appears in software they already have. The flow puts the button inside the vendor’s own plugin, using our free SDK: code the vendor embeds in their own product. The customer clicks Grant Access on a screen in software they already have; their site creates a real WordPress account with the role the vendor configured; the site’s own WP-Cron deletes that account when the window closes. Because the expiry runs on the customer’s site rather than on our servers, a grant that’s already been issued expires on schedule whether or not TrustedLogin is reachable. The customer can also end it early on their own, from a Revoke Access action the SDK adds to their Users list and their admin toolbar.

When a customer’s security review asks who can see the login, the answer is your team, and no one else. The login handoff is encrypted on the customer’s site before it leaves, using a public key belonging to the vendor. The private half lives in the Connector plugin on the vendor’s own site, rather than on the customer’s site or on TrustedLogin’s servers, which relay and store the encrypted login without being able to open it. What we can and can’t see is spelled out here.

The role and the duration are configured once, by the vendor, in the SDK, so the customer sees what’s being requested and grants it or doesn’t, without picking an hour instead of a week from a dropdown. And the hosted audit log keeps 90 days by default, which makes it an operational record rather than an archive.

A site owner installs one plugin; a product company wires it in once

On a site you administer yourself, the free plugin above is the whole procedure.

Putting the button inside your own plugin

On your side, the sequence is:

1. Create a team at TrustedLogin and set the team name, your REST endpoint, and your support URL.
2. Install the TrustedLogin Connector on your own site. The WordPress.org listing, version 2.0.2, requires PHP 7.4. The Connector generates and holds the keypair that decrypts grants, which is why it runs on your infrastructure and not ours.
3. Paste your Account ID, public key, and private key into the Connector, and choose which of your own user roles may log into customer sites.
4. Add the SDK to your plugin and set two values in its config: role, the role customers will grant, and decay, how long the grant lasts. The SDK accepts anything from one day to one month. This is where the promise gets made, so pick the smallest role that lets your team finish a ticket.
5. Connect your help desk if you use one. The Connector ships webhook integrations for Help Scout and FreeScout that put the access-grant button inside the ticket thread.

Step 4 is a composer dependency and a config array. The vendor-side detail is here, and the plans and caps are here.

The reason to do any of this is narrower than security theater and easier to check. The next time a customer files a ticket you can’t reproduce, the distance between “can you describe what you’re seeing” and being in the site looking at it is one click on their end. When you’re done, the account that let you in goes away without either of you doing anything about it. The full walkthrough of every option, including the ones that aren’t ours, is here.