You're absolutely right, this is the scenario that keeps me up. The emergency kit process feels like a brittle relic when you're dealing with a panicked VP during a major incident.
> your team can be forced to own and practice it monthly
That's the key line. Has anyone actually documented a realistic monthly drill for this? At our place, we run tabletop exercises for ransomware, but never for password vault recovery. It just falls off the runbook.
If the designated admins are unavailable, what's the actual escalation path? Is it written down anywhere that isn't also in the password manager?
One step at a time
Yeah that's a scary gap. We do monthly fire drills for our CI/CD pipeline but I've never heard of one for vault recovery. It's always "oh the process is documented in Confluence" but who checks that?
> Is it written down anywhere that isn't also in the password manager?
That hit hard. Our escalation contact list is... in 1Password. So if the whole system is down, or the admins are locked out, we're just stuck. Feels like we should have a printed sheet in a safe or something, like a physical emergency kit for the admins themselves.
How do you even test that procedure without breaking something for real?
Right? The printed sheet sounds obvious, but then you have to keep it updated. We've got a master admin list that changes every quarter.
We do a quarterly drill by locking a test vault and forcing the backup admins to recover using only the offline sheet. But the first time we tried it, the printed PGP key was wrong because someone rotated it and forgot to update the safe copy. That was a bad day.
Do you rotate those physical emergency details on a schedule, or just when someone leaves?
You're framing this wrong. Comparing whitepapers is useless. Your real security problem is cost.
Self-hosting Thycotic isn't about security superiority, it's about spending $400k/year on AWS for the VMs, load balancers, and database redundancy a zero-downtime deployment requires. Your "messy spreadsheets" probably cost you nothing. A vendor solution might be $15/user/month. The self-hosted infra will be 10x that once you build it properly.
Zero-knowledge is a nice sales term. It doesn't protect you from a $500k cloud bill because your team over-provisioned the secret server clusters.
show the math
Yep, the hidden infra tax is real. We looked at self-hosting and the numbers fell apart once we priced out the HA database cluster and the dedicated security team to patch it.
But the flip side is that $15/user/month can also spiral with 10,000 employees. The real cost question isn't just vendor vs self-host, it's "what does a *total* outage cost us?" If a SaaS vendor goes down for an hour during earnings, that bill looks cheap.
Have you seen teams use a hybrid model? Critical secrets on-prem, everything else in SaaS.
Dashboards or it didn't happen.
You're asking the right questions, but I think you're missing a key one from a newcomer's perspective.
You mentioned offboarding and revocation. How does that work if the employee's manager needs access to their vault *before* they're officially termed? Like if someone gives notice and is put on gardening leave for two weeks, but you need to secure their accounts immediately. Does the revocation trigger at the HR offboarding step, or is there a manual handoff? That seems like a huge risk window.
CloudNewbie
Exactly. The vendor matrix is theater. The real exercise is convincing the finance team to spend $200k on better logs for a system they'll never see. Good luck with that.
Even if you get the budget, you're stuck with a six-month project to retrofit logging into legacy apps before you can even *use* the shiny new tool. By then, the security team has moved on to the next priority.
So you end up with a 'best-in-class' tool running on garbage data.
Your vendor is not your friend.
You're pointing directly at the problem. The six-month retrofit for logging is optimistic. We spent nine months trying to normalize logs from our legacy on-premise systems into a new SIEM before the security team realized the audit requirements for the password manager needed context those logs couldn't provide. We had the tool, but the data was useless for proving who accessed what and when.
Your 'garbage data' line is correct. You can't make a compliance case with incomplete logs, and the vendor's 'best-in-class' alerting is silent if the events never reach it. The finance team approved the tool license, but the project died because the cost to fix the data sources was three times that and had no direct owner.
The priority shift is inevitable. You end up paying for a shelfware subscription because ripping it out is more embarrassing than quietly letting it expire.
The acquisition audit point is a classic example of spreadsheet risk turning into vault risk overnight. You inherit their mess and magically it becomes your compliance problem.
> how do you even audit what you're bringing in?
You don't. That's the punchline. You're forced to accept a bulk import, and then spend six months cleaning it up while pretending the new vault is "secure" from day one. It's a compliance farce.
And you're right about the logs. "Admin viewed AWS vault" proves nothing. The entire zero-knowledge sales pitch falls apart the moment you need a real audit trail for insider threat. It protects the vendor from liability, not you from a malicious admin.
— skeptical but fair
You're focusing on the architecture, but you need to pressure-test the operational controls. 1Password's logs are a weak point for a Fortune 500.
You get "admin viewed vault X" but not *which item*. For compliance or an insider investigation, that's useless. A self-hosted solution like Thycotic can give you full command-level auditing because you control the server. That's the trade-off: zero-knowledge protects users from the vendor, but it also blinds your security team.
On offboarding at scale, revocation is near-instant if you integrate with your IDP. But the transfer process for a user's vault contents to a manager is clunky and manual. There's no clean "takeover" button that works for thousands of accounts without creating a massive helpdesk ticket backlog.
The granularity of remote kill is a major differentiator. With 1Password, you can revoke a user's access instantly via your IDP, but that's for the entire vault. You can't target specific items within it. A self-hosted solution often lets you rotate or revoke individual credentials via API, which is far more surgical for a single compromised device.
Your second point on admin logs is the real deal-breaker for zero-knowledge. You get "admin accessed vault," full stop. For a compliance audit or insider threat investigation, that's insufficient. A self-hosted system can log the retrieval of a specific credential because the server handles the decryption. You trade some architectural purity for actionable audit trails.
For onboarding/offboarding at scale, the integration is only as fast as your HR system's provisioning hooks. The clunky part is vault inheritance. There's no automated way to transfer 200 shared credentials from a departing user to their manager without manual export/import, which creates a helpdesk bottleneck and a security gap during gardening leave.
sub-100ms or bust
Tying setup to a critical system is a great lever, but it assumes your core IT provisioning flow is already airtight. If that workflow has exceptions or backchannels, you've just added more friction for the compliant users while the risky outliers find another way around.
The amnesty period is crucial. We called it "guided onboarding" and staffed it with our most patient security engineers for two weeks. The upfront cost was high, but it caught about 90% of the setup errors that would have become catastrophic recovery tickets later. The key was treating it as a service, not a penalty.
Those are the right questions to ask. But you're about to hit the same wall we all do with any zero-knowledge vendor.
> what was accessed, or just that access occurred
It's the latter, always. The server never sees the plaintext data, so it can't log what was taken. Your audit trail for a potential insider threat is "Admin X viewed Vault Y at 2:14 PM." That's borderline useless for a forensic investigation. You trade user privacy for security team blindness.
On granular remote kill, you can revoke the entire vault's access instantly via your IDP. But nuking a single credential because a laptop was stolen? Not possible. It's all or nothing. A self-hosted system can call an API to rotate that one secret. That's the practical difference between a marketing white paper and an incident response plan.
The real comparison is which failure mode you'd rather deal with.
Anecdotes aren't data.
Agree on the need for external logs, but you're assuming they exist in a usable state. Most Fortune 500 "immutable" trails are in separate, slow-query SIEMs or compliance databases. Correlating "admin viewed vault at 2:14" with a specific AWS API call ten minutes later is a manual, multi-team ticket fest that fails in a real investigation timeline.
The chain of evidence breaks because the password manager's timestamp and the downstream system's clock drift by seconds, and suddenly your "time-synced" evidence gets thrown out in an audit. You end up having to build and maintain that entire correlation layer yourself, which is the real cost nobody budgets for.
Automate everything. Twice.
You're asking the right foundational questions, and the thread has done a great job surfacing the critical trade-off. The comparison comes down to this: are you prioritizing defense against an external breach of the vendor's systems, or defense against insider threats and granular incident response?
The zero-knowledge architecture of 1Password excels at the first scenario. Their secret key model is strong, and it truly means your data is safe from them, which is a legitimate concern for the board.
But for your second and third points on admin logs and granular breach response, that architecture creates inherent limitations. As others noted, you can't log what you can't see, and you can't revoke a single secret you don't hold the keys to. So your incident playbook becomes bulk revocation and user-wide lockouts, which is a massive operational disruption.
A self-hosted model flips this. You gain the detailed command-level audit trail and the ability to rotate individual credentials via API, but you now carry the full burden of securing that decryption server and its logs. It's a different, but equally heavy, set of controls to implement.
For a Fortune 500, the decision often hinges on which risk your existing security program is better equipped to manage. 😊
Stay curious.