WordPress connection keys, explained: how TrustedLogin replaces the admin password
You’re reading TrustedLogin’s setup docs, you hit the phrase “site access key,” and you file it next to the last connection key you dealt with: the string you copied out of the ManageWP Worker plugin and pasted into a dashboard to link a site. That one was a bearer credential: whoever held it could add the site. So the reasonable next thought is that TrustedLogin’s key works the same way, and that a support agent holding it holds a login.
TrustedLogin’s key does not work that way, and the difference decides how much care it costs you to handle. Three unrelated things in the WordPress ecosystem are called a connection key, and only one of them is what TrustedLogin means.
Three things WordPress already calls a “connection key”
A dashboard connection key. ManageWP’s Worker plugin generates a string that links a site into a management dashboard. ManageWP’s own guide says “The connection key is available in your WordPress admin area, on the Plugins page, within the Worker plugin’s description,” and the flow is to “Click Use connection key instead and paste the connection key” (managewp.com/guide/getting-started, retrieved September 1, 2026). GoDaddy Pro uses the identical plugin and the identical term: “Certain GoDaddy Pro products, such as Pro Sites and The Hub, use the Worker plugin to connect to your WordPress site,” with instructions to “Select Copy, next to the Connection key box” and “Enter the connection key into whichever product requested it to finish adding your site” (godaddy.com/help, retrieved September 1, 2026). This is a bearer credential in the strict sense: the string is the authorization. Copy it, and you can connect the site.
A stored third-party API key. The other common meaning is a credential for an outside service that a WordPress site keeps on hand: a Stripe key, an analytics token, or an AI provider key. WordPress core has a Connectors screen for exactly this class of credential, and a core proposal published August 25, 2026 by Eric Mann is blunt about where those live today: “Every plugin that needs an API key today writes it to the options table in plaintext.” The same post names what raised the stakes: “a leaked model-provider key is a metered spend liability” (make.wordpress.org, retrieved September 1, 2026). This kind of key isn’t an access grant at all. It’s a long-lived secret your site holds so it can talk to somebody else’s API.
An encrypted site access key. This is the one TrustedLogin means. It shares a vocabulary with the two above and almost nothing else.
| Worker connection key | Stored API key | TrustedLogin site access key | |
|---|---|---|---|
| What it is | A bearer string that links a site to a dashboard | A long-lived credential for someone else’s API | Ciphertext containing a login for one grant |
| Who holds it | Anyone the string is given to | The site, in its own settings storage | Your site, and only after your Connector decrypts it |
| If someone reads it | They can connect the site | They can spend against your account | Nothing; it authenticates nowhere on its own |
| Does it expire | No; it’s valid until the site is disconnected | No; valid until you rotate it at the provider | Yes; the grant’s account is deleted on the customer’s own schedule |
| How you end it | Disconnect the site or regenerate the key | Rotate the key at the provider | Wait for expiry, or revoke from either side |
What TrustedLogin’s site access key is
Set it against the two above. A bearer token authenticates whoever holds it; holding this authenticates nothing. An API key is proof of identity to the service that issued it; nothing accepts this one as proof of anything. And an admin password opens a site on its own, which this never does.
What it is: ciphertext, produced on the customer’s site, that only your site can open.
When a customer clicks Grant Access inside a product built with TrustedLogin’s SDK, their site creates a new WordPress user account scoped to the role your plugin is configured to request, then encrypts that account’s login secret before anything leaves their server. TrustedLogin’s docs describe the primitive precisely: “Login credentials are encrypted using Sodium sealed boxes using keys generated using on the Vendor website,” and the encrypted envelope is then stored server-side: “Secrets are encrypted and stored using the Sodium Secret Box algorithm in the Hashicorp Vault” (docs.trustedlogin.com/security, retrieved September 1, 2026).
In TrustedLogin’s architecture the “vendor” in that sentence is you, the plugin or theme company whose support team is being granted access. The keys that open a grant are generated on your infrastructure, not the customer’s and not ours.
Why it can’t be intercepted and reused the way a Worker-style connection key can
A Worker connection key has one security property that matters: it must stay secret, because the string is the access. If it appears in a screenshot, a support ticket, a Slack channel, or a log file, whoever reads it can act on it. That is the nature of a bearer credential rather than a flaw in the design, and every product that uses one carries the same handling burden.
TrustedLogin’s site access key inverts that. The value that travels is already encrypted, and the material that would decrypt it never travels at all. Someone who intercepts the envelope in transit, or reads it out of storage, holds a blob that authenticates nothing. There’s no endpoint that accepts it, no site it logs into, and no replay to perform.
The reason is where the encryption happens and where the key lives. Encryption happens client-side, on the customer’s own server, before the envelope is transmitted, so there is no window in which the plaintext credential exists on any wire or in any datastore of ours. And the decryption key isn’t stored alongside the ciphertext, because it isn’t stored on our systems at all.
Where the key lives, and who can decrypt it
When a customer’s security review asks where the key sits, this is the answer, in the order it happens.
The customer’s site encrypts, using your public key. It never decrypts anything and never holds a decryption key.
The decryption key lives on your own site, inside the Connector plugin. Our security page states it directly: it is “a long-term keypair generated and held on your own site by the Connector plugin, reused across grants until you rotate it.” When your authenticated support agent clicks Log In, the Connector decrypts the grant locally, on your infrastructure, and the customer’s site verifies the result. Nothing decrypts on TrustedLogin’s servers at any point.
TrustedLogin’s servers hold ciphertext and metadata. We store and relay the envelope. We never hold the key that opens it, which is why a promise not to look would be redundant: there is nothing to look with.
Not everything in a grant is encrypted, and you should know which parts aren’t. TrustedLogin’s own technical docs state it: “The ID of the user who granted access to the website, the URL of the website where access is being granted as well as vendor-defined array of metadata are stored unencrypted” (docs.trustedlogin.com/security, retrieved September 1, 2026). The login credential is sealed; the routing information around it is not. The practical consequence is for developers integrating the SDK: the vendor metadata array is a place to put a ticket number or a plan name, not a place to put a secret.
What happens between the customer’s click and your agent’s login
Here is where the key sits at each step:
- The customer clicks Grant Access inside your plugin’s own admin screen. They see the access window and the role your plugin is configured to request, settings you chose when you integrated the SDK rather than a menu they pick from.
- Their site creates a scoped WordPress account for that role, a real user on their own install.
- Their site encrypts the login secret with your public key, before anything leaves their server, and stores a hash locally so it can verify the eventual login request.
- The encrypted envelope goes to TrustedLogin and is stored. We can route it, expire it, and log that it exists. We cannot open it.
- Your agent clicks Log In, from the Help Scout ticket or the dashboard. The Connector on your own site decrypts the envelope with the private key that has never left it, and completes the login against the customer’s site.
- The grant ends. The account is deleted on schedule by the customer’s own site, on its own cron, so expiry doesn’t depend on TrustedLogin being reachable. The customer or their host can also revoke it at any time directly in wp-admin, with or without us.
What lands in the audit log is the metadata, not the credential: which site, which of your support agents logged in, what role they had, when the session started and when it ended, kept 90 days.
The test that tells the two apart
Calling this a “key” invites the ManageWP comparison, which is where the misreading starts. A Worker connection key is a password-equivalent: something to guard, rotate, and never paste anywhere. TrustedLogin’s site access key is closer to a sealed envelope addressed to one recipient: it can sit in a log without being a liability, because the thing that opens it was never in the same place.
The practical test is the one to keep: if a credential’s security depends on nobody ever seeing the string, it’s a bearer credential, whatever it’s called. If it depends on a key that never traveled, it isn’t. Every “connection key” on this page falls on one side of that line or the other, and knowing which one you’re holding decides how carefully you have to handle it.
For the flow drawn out end to end, see how it works. For what a support team does with this on an ordinary Tuesday, the access how-to covers the alternatives it replaces, and the password-manager comparison covers the vault entry it retires.