How to give your support team access to a customer’s WordPress site (without emailing a password)

A customer just pasted their WordPress username and password directly into a support ticket, in plain text, because nobody on either side of the conversation told them a different way to hand it over. It’s sitting in your help desk now, probably synced to three inboxes, possibly forwarded to a second agent already. Before you do anything else, that’s the first problem to close.

Asking for a fresh password moves the same problem

The obvious instinct is to reply “please reset your password and send the new one instead.” Don’t. That fixes nothing: it’s the same plaintext credential moving through the same channel one more time, and it trains the customer that emailing a password is the normal way to work with your support team. The credential in the ticket also isn’t gone once you’ve read it: it’s in your help desk’s database, in your customer’s sent-mail folder, and in whatever inbox rules forwarded a copy along the way. Rotating the password later helps; it doesn’t undo the exposure that already happened.

The fix is to stop asking for the customer’s password at all, and ask for something scoped instead.

Three ways to get in without a shared password

The three are not interchangeable; each answers a different question.

Application Passwords

Built into WordPress core since version 5.6 (December 2020), Application Passwords let a user generate a per-application credential from their profile screen, shown once at creation. It’s revocable on its own without touching the account’s main login password, and WordPress requires HTTPS for any request that uses it.

What it doesn’t do is police who creates one or why. There’s no built-in consent screen unless a developer adds one; the credential appears once generated. It carries whatever role the underlying WordPress account has, which for a site owner is typically Administrator, meaning the full account, not a scoped slice of it. And it doesn’t expire on its own; it sits in the profile until someone remembers to delete it. This is the exact mechanism that put Rank Math’s plugin in the news in August 2026: an Administrator-level Application Password created automatically, with no consent screen and no expiry, as soon as a site owner opened the plugin’s support panel.

Use Application Passwords for what they’re built for: a script, an integration, a REST API client authenticating on its own, rather than for handing a human support agent a login. If you do generate one for a support session anyway, at minimum name it for the ticket (“Support, HS #4821, expires 2026-09-08”) so a future audit of the Application Passwords list tells you something, and delete it, through the profile screen or wp user application-password delete, as soon as the ticket closes rather than leaving it for a cleanup pass that may never happen.

A temporary-login plugin

Temporary Login Without Password generates a link that logs whoever clicks it straight into WordPress, at a role and expiry you choose: an hour, a day, a week, a custom date. It’s free.

The tradeoff: the link is the credential. Anyone holding the URL is logged in, with no step that confirms the person on the other end is the support agent you meant to authorize rather than whoever the link got forwarded to. It also has to be installed and set up on each site individually. Fine for a one-off; a real constraint if your team is doing this across a large customer base.

TrustedLogin

Your agent stops asking for a login and starts fixing on the first reply. The customer clicks Grant Access inside your own product, via TrustedLogin’s free SDK embedded in your plugin’s own UI, and WordPress creates a scoped account on their site that expires on the schedule your plugin was configured to request, which you set once when you installed the SDK rather than choosing it per request. What reaches your support agent is an encrypted site access key, decryptable only while that agent is authenticated into their own account, so no working login is ever sitting anywhere a third party can read it; the full exchange is written out at how it works. Sessions are recorded, so when a customer asks who was in their site last month you answer from a list instead of from memory.

The tradeoff going the other way: it’s a paid product (Support $49/mo · Growth $99/mo · Scale $249/mo · Enterprise from $499/mo), and it assumes a support team logging into sites it doesn’t administer. For a one-off on a site you run yourself, the free plugin above covers it.

Name what the ticket needs instead of asking for admin

Whichever mechanism you use, the request should name what the ticket requires rather than default to the broadest role available. WordPress has no read access to plugins to ask for: a role is a set of capabilities, and most plugin settings screens are gated on manage_options, the capability that also opens every other settings screen on the site. So “I need to see your Contact Form 7 settings and check a plugin conflict” gets answered with a smaller account or a shorter one. A lower role closes the ticket outright when one fits, like Editor for a content problem or Shop Manager for a WooCommerce order. Where it doesn’t, a custom role can carry only the capabilities the work needs, which is what the TrustedLogin SDK builds from the role your plugin configures. And where the job really does take Administrator, the thing to narrow is how long the account lives. These questions settle it:

1. Does this expire, or do I have to remember to remove it? An account that outlives the ticket is an account nobody’s watching.
2. Is it scoped to what the ticket needs, or does it carry the full site? The Essential Plugin supply-chain backdoor sat dormant for roughly eight months (planted in an August 2025 update, activated April 5, 2026) before serving anything, a reminder that “who has standing access to this site’s code” is worth continuous attention, not a one-time check.
3. Is there a record of who used it and when? If the answer’s “a login-count number,” that’s not an answer to “who was on this site.”

An Administrator role that fails all three questions is still the default most support tickets reach for, because it’s the fastest thing to grant. It’s also the thing sitting in Rank Math’s August 2026 incident, unrevoked, on every site where a user didn’t know to go looking for it: a credential nobody asked for, at full account privilege, created as soon as a support panel was opened rather than when access was needed.

Setting it up once so your team stops asking

The fastest way to stop this pattern from repeating is to settle the decision before a ticket lands. Pick one mechanism as your team’s default. Application Passwords are for a program calling the REST API on its own; a temporary-login plugin is for a one-off on a site you administer yourself; and whenever a person on your team has to be inside a customer’s site, that’s TrustedLogin: a scoped account the customer approved, on a clock, with a record of who used it. Write the request template your agents paste into a ticket, and put it in your macros so nobody’s improvising a “just send me your login” reply under deadline. A macro that names the mechanism explicitly (“Here’s a link to generate a temporary login, so there’s no need to share your password” or “Click Grant Access on the Support screen in [Your Plugin]”) also does the customer-education work for you, every time, without anyone having to remember to explain it.

The password-in-plaintext ticket that started this came from a workflow that never gave the customer anything else to do. Fix the workflow once, and the next customer with the same bug never has to make the choice that got this one’s credential into your help desk in the first place.