What we can see. What we can’t.
An accounting of the architecture, including the parts that would hurt us if we’re wrong about them.
What we can see
Metadata: which site requested access, which of your support agents was granted it, what role, for how long, and when the session started and ended. That’s what powers the audit log. It’s also data TrustedLogin holds.
What we can’t see
The decrypted login itself. When a customer grants access, their site encrypts the login secret before it leaves their server, using your public key. The private key that decrypts it lives on your own site, inside the Connector plugin, and never leaves it. Our servers store and relay ciphertext. There’s no step in the flow where the plaintext credential passes through anything we operate. The key to open it is never on our infrastructure to begin with, so a promise not to look would be redundant.
Key handling
The decryption key 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 logs in, the Connector decrypts the grant locally and the customer’s site verifies the result; nothing decrypts on TrustedLogin’s servers at any point. The full technical writeup, including the message schema and exactly what’s stored where, is at docs.trustedlogin.com/security. The diagrammed version of the flow is at docs.trustedlogin.com/flows.
One-time secrets
Secrets — a password, an API key, anything your team needs to hand a customer once — work differently from a grant: they never touch our servers at all. They’re created, encrypted, and stored entirely on your own WordPress site, inside the Connector. The decryption key lives only in the link’s URL fragment; your site stores ciphertext and a one-way hash of that key, nothing that opens it. Single-view secrets are destroyed the moment they’re read; reusable ones live until an expiry you set, up to 30 days. Every secret leaves a record on your own site: created, viewed, from where, kept 90 days.
If TrustedLogin is unreachable
A grant already issued doesn’t depend on TrustedLogin staying up. It’s a real WordPress account on the customer’s own site, with its own expiry, independent of whether our service is reachable when your agent tries to log in. If the SaaS itself is down, the Grant button in your plugin degrades to pointing the customer at your own support page instead of erroring out.
If TrustedLogin goes away
The SDK is open source on GitHub, and the Connector is GPL-licensed with its source shipped through WordPress.org. If TrustedLogin the company stopped operating tomorrow, the code embedded in your product and the plugin installed on your site don’t stop working. You’d lose the hosted dashboard and the cross-site audit log, not the ability to keep running your own grant flow, because none of it depends on a proprietary client you don’t have the source to. And because every grant is a real account the customer’s site created, the customer or their host can always revoke it directly in wp-admin, with or without us.
Verify it yourself
This page is the plain-language version. The engineering version, key formats, message schemas, what’s logged where, and how to run a Connector setup behind a reverse proxy, is at docs.trustedlogin.com, maintained in the open at github.com/trustedlogin/docs.