You're trusting us with company logins, so here's the real architecture — what's encrypted, what's not airtight, and what we still need to build. Skip ahead if you just want the short version: we encrypt everything, employees never see the password, and we haven't been audited yet.
Here's exactly what happens from the moment you save a credential to the moment an employee logs in.
Every password is encrypted using AES-256-GCM, the same standard used by the US government and major financial institutions. GCM mode provides both confidentiality and integrity checking, meaning any tampering with encrypted data is detectable. A unique initialization vector (IV) is generated for each encryption operation.
All communication between the extension and our servers uses HTTPS/TLS 1.3. Passwords in transit are encrypted. A network observer intercepting traffic would see encrypted data, not credentials. Our server enforces HTTPS, so unencrypted connections just get rejected.
After autofill, CorpVault actively prevents the show-password toggle from working using a combination of browser-level techniques. The extension continuously monitors the page and neutralizes any attempt to reveal the password through the page's interface, including buttons that reappear after the page re-renders. We don't publish the exact mechanism here, the same way a lock manufacturer doesn't publish a how-to for picking it. The result holds up across the vast majority of sites we've tested.
Employees receive a JWT auth token — not the actual password. The token proves they're authorized to request autofill for their company's credentials. When an employee is removed, their token is invalidated immediately on our server. Even if a former employee still has the extension installed, their token will be rejected.
When you remove an employee from the admin panel, their access is revoked immediately. Not on next login, not at the end of the day, right then. Their auth token is invalidated server-side. The next time they visit any site, the autofill request gets rejected. They never had the password, so there's nothing to "take with them."
Our backend runs on Railway with managed PostgreSQL on US-based servers. Passwords are never written to disk in plaintext; encryption happens in memory before storage. Database connections use SSL. The server enforces rate limiting on all auth endpoints to prevent brute force attacks.
No password tool blocks everything. Here's specifically where ours stops, and where it doesn't.
| Threat | Our Protection | Status |
|---|---|---|
| Employee reads the password from the UI | Show-password button disabled. Password injected as dots only. No UI element displays it. | ✓ Blocked |
| Employee inspects network traffic | All traffic is TLS encrypted. They'd see encrypted bytes, not credentials. | ✓ Blocked |
| Employee accesses credentials after being fired | Auth token invalidated immediately on removal. Server rejects all subsequent requests. | ✓ Blocked |
| Database breach | Only encrypted blobs stored. AES-256-GCM encrypted data is computationally infeasible to decrypt without the key. | ✓ Protected |
| Employee uses authenticated session after login | CorpVault fills the login form. Once logged in, the site's own session management takes over. A determined employee could copy cookies from an active session. | ⚠ Partial |
| Employee has local admin rights on their PC | A user with local admin rights and sufficient technical knowledge could potentially access browser memory. This is a risk with any browser-based tool including LastPass and 1Password. | ⚠ Partial |
| Employee uses account after termination via saved session | CorpVault removes their ability to log in again. However if they were already logged in with an active session before removal, that session may persist until it expires. Enable MFA on critical accounts. | ⚠ Partial |
| Independent security audit | We have not yet completed a third-party security audit. This is on our roadmap as we grow. We operate transparently about this limitation. | Roadmap |
| SOC 2 Compliance | Not yet certified. SOC 2 audits are expensive and typically pursued at scale. We plan to pursue this as the company grows. | Roadmap |
| Audit logging | Basic logging exists. Full audit trail showing who accessed what account and when is on our active development roadmap. | Roadmap |
Start with vendor and supplier accounts — parts portals, warranty sites, dealer service portals, training systems. These are perfect use cases with minimal risk.
Social media accounts work great — employees can post and manage without knowing the password.
For bank accounts and payment portals — enable multi-factor authentication (MFA) on the account itself. MFA is the single best additional protection for high-value accounts, regardless of what password manager you use.
For critical admin accounts (QuickBooks, payroll, email admin) — consider whether employees actually need access, or just you. CorpVault is for shared team access; solo admin accounts may not need it.
They can't read the password — that part's solid. What we can't stop is someone copying an active session after they're already logged in, but that's true of literally every password manager and SSO tool out there, not just us. The real difference: they never have the password itself, so they can't log in from their own phone later or hand it to a friend. They're stuck using the session on the machine you control.
No. Everything between our server and the extension runs over TLS, so a network sniffer just sees encrypted bytes.
Then there's a theoretical path to poking around in browser memory, and we're not going to pretend that risk is zero. Same caveat applies to 1Password, LastPass, Bitwarden — any browser-based tool, really. Chrome's sandboxing helps a lot but isn't a hard wall. If someone's that high-stakes, the device itself needs to be locked down too.
They lose the ability to log in again immediately. But if they were already logged into something before you removed them, that existing session can stick around until it naturally expires. For your most sensitive accounts, log out their active sessions from that site directly too — don't rely on CorpVault alone for that.
No, not yet. Audits cost real money and we're early. Reach out at hello@corpvault.app if you're a security researcher and want to poke at it.
You can pull your credential list (usernames and URLs, not passwords) from the admin panel whenever you want. If we ever did shut down, you'd get at least 30 days notice and a full export first.
Chrome and Edge work today since they share the same extension engine. Firefox and Safari aren't built yet — on the list, not done.
Start with your vendor accounts. See how it works. Scale from there.
Start 14-day free trial →