Password & Secrets Management
Your client passwords stay in 1Password. Solidlio links them to the assets, tickets, runbooks and sites they belong to — and records who revealed what, when, and why.
How Solidlio helps
Solidlio does not become a second password vault. It stores a reference to each item in your password manager — the vault, the item, its title, its category, when it was last changed — and links that reference to the asset, ticket, runbook or site it belongs to. When a technician needs the value, it is fetched from the password manager at that moment, over one authenticated request, and the request is recorded before it is even made.
A compromise of the Solidlio database yields zero credentials, because there are none in it.
Capabilities
| Capability | What it does |
|---|---|
| Credential inventory | Syncs item metadata from your vaults — title, category, tags, URLs, last-changed. Never values. |
| Vault → client mapping | Each 1Password vault maps to a client organization. An unmapped vault imports nothing; Solidlio never guesses whose credential it is. |
| Linked to the work | A credential attaches to an asset, a ticket, a knowledge-base runbook, a Scribe guide, a site, a change, a contract or a vendor. |
| Reveal in context | A technician reveals a field from the ticket they are already reading. The ticket rides along on the audit record. |
| Link-only mode | Solidlio brokers nothing and renders an “Open in 1Password” link instead. The technician authenticates as themselves, so 1Password’s own log names them. |
| Reason and ticket capture | Configurable per connection and per item: require a ticket, a written reason, or both. |
| Step-up on sensitive material | SSH keys, certificates and anything tagged break-glass require a recent sign-in before they can be revealed. |
| Per-person reveal limits | Caps bulk credential harvesting from a compromised session — and stops one technician exhausting the tenant’s password-manager rate limit. |
| Full access trail | Every reveal, every refusal, every provider failure, with actor, field, reason, ticket, IP and time. Append-only. |
| Out-of-band detection | Reconciles 1Password’s own Events API against Solidlio’s trail and reports credential access that did not go through Solidlio. |
| Token-misuse alert | Flags use of Solidlio’s own service account from anywhere that is not Solidlio. |
| MSP multi-tenancy | One connection per client tenant; credentials are filed under the client, never the MSP, and MSP_INTERNAL items never render on a client’s page. |
How the audit trail actually works
This is the part worth being precise about, because a competitor’s marketing will not be.
Every read Solidlio makes goes through one service account. 1Password therefore attributes those reads to the integration, not to the technician — there is no on-behalf-of in any password manager. So:
- Solidlio’s record is the authoritative “who.” It is written before the password manager is contacted, so a refused or failed reveal is on the record too. An audit trail that only records successes is not an audit trail.
- 1Password’s record is the cross-check. Solidlio stamps 1Password’s event id onto its own row so an auditor can follow one access through both systems.
- The disagreements are the point. A 1Password item usage with no Solidlio reveal behind it means someone went around the tool — legitimate, and worth seeing. The same usage attributed to Solidlio’s own service account means the token is being used somewhere it should not be. Nothing else in either product can detect that.
If you would rather 1Password’s log named your technicians directly, run the connection in link-only mode. Opening the item requires each technician’s own 1Password account and vault permissions. Reveal mode is configured per connection.
What it deliberately does not do
| Work offline | If the password manager is unreachable, Solidlio cannot reveal. That is the trade for holding nothing, and the “Open in 1Password” link still works from the technician’s own app. |
|---|---|
| General password-manager editing | General editing and rotation are not provided. Certificate-key creation is an explicit opt-in requiring provider write permission. |
| Replace your password manager | Your policies — MFA, device trust, travel mode, Watchtower — keep applying, because the credentials never leave their custody. |
Providers
1Password ships. The integration is written against a provider-agnostic contract — the same shape the remote-support feature uses — so Bitwarden, Keeper, Devolutions, Passportal, HashiCorp Vault and Azure Key Vault are one adapter each, with no change to the asset panels, ticket panels, inventory or audit trail.
1Password requirements. A service account (any 1Password Business or Enterprise plan) for the credential inventory. The out-of-band detection additionally needs an Events Reporting token, which requires 1Password Business.
Plan availability
Included from the mid tier upwards (MSP Growth and above; Customer Professional and above). No per-seat or per-credential charge.
Access and audit update — September 2026
Linking an MSP’s 1Password reference to a customer’s asset does not share the MSP’s connection with that customer or another MSP. Customer-owned connections retain their own permissions. Credentials and link targets must be placed under the same organization.
Reads require durable audit evidence, and field discovery uses the same policy as revealing. Audit attempts start pending; outcomes complete once. The browser avoids both query and mutation caches for revealed values. The Business Events API imports item usage, account audit and sign-in evidence; matching requires an administrator-verified service account UUID. Disconnect preserves history. Operational retention and independent evidence archiving are still required; this is not a SOC 2 certification claim.
Plans and access
Availability depends on your plan, role and account permissions. Capacity limits and service terms apply. Compare current plans and integration requirements, or ask us about your setup.