Your customer clicks Grant. Your support agent logs in. Nobody sees a password.

TrustedLogin brokers the WordPress login between your support team and your customer’s site. The exchange is encrypted before it leaves the customer’s server. TrustedLogin cannot read the credential it delivers. Whenever a customer asks, your team is in there in minutes, fixing instead of describing, with a record that they left.

The consent screen a customer sees inside GravityView:

The ticket that starts with a password

A customer replies to a support ticket with their WordPress username and password, typed in plain text, sitting in your help desk forever. Or your team asks them to create a temporary account and walks them through Users → Add New over email, then waits. Either way, a credential just traveled through a channel built for prose, not secrets.

TrustedLogin is the alternative to both the ticket-thread password and the in-house bridge: the customer clicks a button inside your plugin, sees the access window and role you configured, and your team logs in through a session that expires on that schedule, with a record of who logged in and when.

How the grant works

1

Your customer clicks Grant Support Access inside your plugin, through the free SDK you embedded.

2

Your plugin creates a scoped WordPress account on their site: not your account, a new one, with the role you asked for.

3

The login secret is encrypted before it leaves the customer’s server, with a key that lives on your own site, inside the Connector plugin. TrustedLogin’s servers relay and store ciphertext; they hold nothing that opens it.

4

Your support agent logs in from Help Scout or the TrustedLogin dashboard. Access ends on the schedule you configured in the SDK: days at most, never indefinitely.

5

Every login is on the record: who, which site, what role, when it started, when it ended.

The TrustedLogin Sites screen listing every customer WordPress site that has granted the team access, with columns for Site, Connected, Expires, Access Key, Last login and Status, and a Log in button on each row.

What this replaced, in hours

At GravityKit, before TrustedLogin, a ticket that needed site access ran like this: customer submits a ticket overnight, 8 hours to first response.

Support determines it needs site access and emails the customer asking them to create a login, 8 hours 15 minutes.

The customer responds with credentials, hours later, 12 hours.

The login doesn’t work; another round of emails, 16 hours.

Sixteen hours in, the bug is still just a description in a ticket, because nobody has been able to see the site yet. TrustedLogin replaces those four emails with one click, and the customer’s wait with someone actually looking at the site.

Who this is for

TrustedLogin is built for support teams: two or more people logging into customer WordPress sites every week, at plugin and theme companies and at agencies running a client fleet.

If you’re doing a single one-off fix on somebody else’s site, install the free Temporary Login Without Password plugin on that site and skip this page; it costs nothing and takes a minute per site.

TrustedLogin earns its cost once site access is a routine part of your week, not an exception to it.

Who’s already running it

Teams at GravityKit, SendWP, Content Control, and Hubbub use TrustedLogin in their support flow today — GravityKit dogfoods it daily (2,589 logins across 1,789 sites since August 2024, roughly 38 a month lately), and Hubbub has been a paying customer since April 2026.

“We’ve implemented TrustedLogin at LearnDash and the team and customers LOVE IT. Such a great UX. We had so many awkward back and forths previously, and now it’s just BOOM, DONE, and secure all at the same time.”

Matt Cromwell, then Senior Director of Customer Experience, StellarWP (LearnDash’s parent at the time)

The architecture, summarized

TrustedLogin can’t decrypt the login it hands your support agent. The key that opens it never touches our servers; it lives on your own site, in the Connector plugin you installed. If TrustedLogin is unreachable, the Grant button in your plugin falls back to pointing your customer at your own support page instead of failing silently. If TrustedLogin the company disappeared entirely, the SDK inside your plugin and the Connector on your own site keep working, because the SDK is open source and the Connector’s source ships through WordPress.org, not dependent on us staying in business.

Sequence diagram titled Support Access Flow across three columns, Client Site, SaaS and Vendor Site: the user grants access, the client requests the vendor's public key, the vendor generates a keypair and keeps the private key locally, the envelope containing login tokens is encrypted with the vendor's public key, and the encrypted envelope is sent to TrustedLogin, which stores it encrypted at rest.

One-time secrets

When a credential has to travel

Sometimes the fix isn’t a login, it’s one piece of information: an API key, a database password, a third-party token. The Connector includes one-time secrets for that. Your team pastes it in, sets when it disappears, single read or a chosen expiry, and hands the customer a link instead of typing the value into the ticket. The decryption key lives in the link itself, in the part your browser never sends to any server, so the secret is gone the moment it’s read or its clock runs out, whichever comes first.

What’s next

We’re extending the same grant to AI agents next: scoped, time-boxed, revoked like every other session.

Pricing

Support teams of two to three people typically run on the $49/mo Support plan.

Give your support team a login, not a password.