The grant flow, from both sides
One click for the customer. One click for your support agent. In between, a key exchange neither side has to think about.
What the customer sees
1
They’re in a support ticket and your reply says access would help. Inside your plugin’s admin screen, or a link you send, is a Grant Support Access button, added by the TrustedLogin SDK you embedded.
2
They click it and see, in plain text, the access window and the role your plugin is configured to request. You set both when you installed the SDK; the customer’s choice is grant or don’t.
3
Behind that click, their site creates a new WordPress user account scoped to that role, and encrypts its login secret before anything leaves their server.
4
They see a confirmation and a countdown to expiry. They can revoke access themselves, any time, from their own wp-admin.
What your support agent sees
1
A note appears in the ticket (Help Scout, if the Connector is installed) or in the TrustedLogin dashboard: this customer has granted access, expiring in [duration].
2
They click Log In. Because they’re authenticated to your team’s TrustedLogin account, the encrypted grant is decrypted on your own site by the Connector, using a key that has never left it, and the customer’s site verifies the result and completes the login on its own.
3
They do the support work. When the grant expires, the account is gone on its own; nobody has to remember to clean it up.
4
If the ticket resolves early, either side can revoke access before the timer runs out.
The cryptography, in plain words
TrustedLogin’s servers relay an encrypted blob. They store it, route it, log that it moved, but they never hold the key that opens it. That key stays on your own site, inside the Connector plugin, the entire time. “TrustedLogin can’t read the credential it delivers” isn’t a policy we promise to follow; it’s a step the system is built to skip. The full technical writeup, including the actual message flow, is at docs.trustedlogin.com/security, and the diagrammed version is at docs.trustedlogin.com/flows.
What’s in the audit log
Every grant leaves a record: which site, which of your support agents logged in, what role they had, when the session started, and when it ended (by expiry or by revocation). The log is kept for 90 days; the Connector keeps its own copy on your site.
One-time secrets
When a credential has to travel
Not every ticket needs a login; sometimes it needs a password, an API key, a connection string. One-time secrets handle that separately from the grant flow: your team pastes the value in, chooses single-view or a set expiry up to 30 days, and gets back a link to send instead of typing the secret into the ticket. The decryption key lives only in the link’s fragment, the part after #, which never reaches any server — not your site’s, not TrustedLogin’s. An optional passphrase adds a second factor, checked with a growing delay after each wrong guess. Every secret leaves its own record: who created it, when it was viewed, and from where, kept 90 days.
Who this is for
Support teams at plugin and theme companies, and at agencies running a client fleet: two or more people logging into customer sites every week.
Not a site-management tool. No backups, no updates, no uptime monitoring, no client dashboards. TrustedLogin does one job: getting your team into a customer’s site when they ask, and out again.
For developers
Configuring roles, durations, and where the button appears in your plugin is a Client SDK setting, not a support-desk one. Full configuration reference and a working example plugin: docs.trustedlogin.com.