How to choose the right level of PAM vault security

I talk with a lot of customers about their identity security challenges. Most have a good handle on protecting human access to infrastructure with strong authentication and least privilege.

Few of those teams have the budget for a dedicated organization whose only job is continuous credential protection.

So how much vault security do you actually need? That answer changes what you buy, what you build and what you can defend in an audit.

Customers evaluating PAM vault security ask the same question in different words: "How do I know if my secrets are actually safe?" The clearest way I can answer it is with a physical-world analogy using safes, private vaults and institutional depositories because it turns an abstract cryptography question into something anyone can understand.

This post walks through that analogy in Q&A form, including a real lesson from customers who insist on self-hosting can get to a genuinely strong tier on their own, but the tier above that requires manpower, cost and continuous audit that only a dedicated vendor can sustain at scale.

What's a useful way to think about "how secure is my vault," without getting lost in cryptography jargon?

An easy way to think about it is to map it to something everyone already understands: physical security tiers. A vault's assurance roughly falls into three tiers, each with a real physical-world equivalent:

Each tier trades something for something: more assurance for less self-sovereignty, or vice versa. None of the tiers is "wrong", but the point is knowing which one you're actually on, and what it would cost to move up.

What does it take to build a private PAM vault?

Most customers deploying a PAM vault sit at Tier 1. Here, the software itself is solid, but the master encryption key is typically protected by the vault's own software-based key store rather than a customer-controlled cryptographic module.

To move to tier 2, you’ll need three things layered together, not one HSM purchase. You'll need:

• hardened infrastructure PAM controls on the vault's own host/OS layer. This includes AD bridging, privilege elevation and session control on the servers running the vault, not just role separation inside the vault application.

• high availability across fault-tolerant sites, so the key material doesn't depend on a single site or host surviving.

• a dedicated, customer-owned HSM (FIPS 140-3 Level 3, ideally Common Criteria EAL4+ with AVA_VAN.5) performing bring-your-own-key encryption, with split-knowledge (M-of-N) administration so no single admin can reconstruct the key alone.

Customers who have all three genuinely achieve a strong tier. The catch: It's entirely self-attested. Nothing about it is independently verified unless the customer separately pays for a third-party audit or penetration test.

How protected is a "fireproof" safe compared to an institutional vault?

The simple answer is less than you would think, and less than most people assume. Understanding why matters because it maps directly onto the Tier 1 vs. Tier 3 gap. Underwriters Laboratories publishes two entirely different standards, for two entirely different classes of product, and conflating them is where the confusion comes from.

• UL 687 rates standalone, movable safes. They measure how long a single self-contained box holds out against expert tools and cutting torches.

• UL 608 rates something categorically different: vault doors and modular panels built into the floors, walls, and ceilings of financial institutions. The structure itself delivers the burglary resistance, engineered and installed as a system.

Vault security in identity security works the same way. A hardware security module (HSM) can be the best product in its category and still leave you at Tier 1 because Tier 3 assurance comes from how a PAM vault is architected, operated and monitored, not from how much you spend on the component inside it.

Buying a better HSM never gets you an institutional-grade PAM vault. A certified control covers the specific class of threat it was certified against, and topping out one category doesn't carry you into the next.

What does a tier 3 institutional depository add that a customer-built tier 2 private vault can't?

Two things a private vault, by definition, doesn't have: an independent operator and an independent auditor who are deliberately not the same party as the asset owner. Texas Bullion Depository and IBV International Vaults are the physical-world model:

1. A third-party operator runs the facility.

2. Storage is segregated per depositor rather than pooled.

3. The arrangement is independently audited (state oversight, third-party accounting audits).

4. Losses are backstopped by an all-risk insurance policy.

That's the same structure as a SaaS vault with customer-managed keys (BYOK): The vendor operates the infrastructure but never holds the unwrapped key. Per-tenant key material is segregated rather than pooled, and the whole arrangement is independently audited via SOC 2 Type II, or FedRAMP, rather than self-attested like a Tier 2 setup is.

The trade is real; a depository (and a SaaS vault operator) can be legally compelled to assist access. But a self-built private vault cannot be compelled at all because no outside party has standing to compel it. Institutional-grade, continuously verified assurance is being traded for a small amount of self-sovereignty.

Why can't customers reach Tier 3 on their own?

Even with an unlimited hardware budget, there are two things hardware can't buy: independent verification and continuous operational discipline at scale. A customer can purchase an HSM as capable as anything Delinea runs. What's genuinely hard to replicate is:

• 24/7 continuous monitoring and incident response across the full lifecycle of the vault, not just at the moment a control was configured.

• independent third-party audit on a recurring cadence (SOC 2 Type II, FedRAMP) rather than a one-time penetration test the customer commissions themselves.

• a dedicated team tracking the post-quantum cryptography migration timeline across every HSM and every algorithm in the chain. For example, NIST IR 8547 deprecates RSA-2048/ECC P-256 after 2030 and disallows them after 2035; CNSA 2.0 targets 2033 for national security systems. Keeping every customer-owned HSM's firmware current against that schedule, on top of everything else IT already does, is a standing tax most internal teams don't have headcount for.

• split-knowledge staffing depth; because M-of-N administration only works if there are enough trained, available custodians that losing one doesn't create a single point of failure, which is a real staffing cost most organizations underestimate.

None of this is a knock on any customer's engineering talent. It's a manpower and cost argument. Maintaining Tier 3-grade assurance continuously, for one tenant, doesn't amortize the way it does for a vendor running the same controls across every tenant at once.

Should a customer self-host their vault, or use the SaaS service?

For customers who want the strongest achievable security posture, the SaaS service with customer-managed keys is the better answer. Not because self-hosting is wrong, but because Tier 3 assurance is structurally a scale business, and self-hosting tops out at Tier 2 no matter how much a customer invests.

The SaaS model gives customers everything Tier 2 gives them (their key never leaves their control under BYOK) plus the two things no amount of customer-side spending can replicate: independent audit and continuous operational depth spread across a dedicated security organization instead of an internal team.

That doesn't mean self-hosting is a bad choice. Some customers have real regulatory or jurisdictional reasons to stay at Tier 2, and that's a legitimate call to make.

But "we'll just do it ourselves and it'll be more secure" is usually the wrong assumption. The UL 687 vs, UL 608 lesson applies here too: A control that looks impressive on paper is only as good as the specific conditions it was actually tested against. Few internal teams have the resources to test their own setup as rigorously, or as continuously, as an independent auditor.

Doesn't the CLOUD Act make self-hosting the safer choice regardless?

The CLOUD act is the strongest legitimate reason to consider Tier 2, and we take it seriously. A US-based SaaS vendor can, in principle, be compelled under the CLOUD Act to produce customer data, potentially under a gag order that prevents the customer from ever knowing.

Secret Server Cloud supports customer-managed encryption keys through two third-party providers that the customer fully controls: Azure Managed HSM Service (a FIPS 140-3 Level 3 validated HSM) or AWS Key Management Service.

When configured, the external key is generated and held entirely in the infrastructure the customer owns, and Secret Server is granted only limited access to it. Delinea is never in possession of the raw key material.

That arrangement puts a genuine kill switch in the customer's hands: The customer can revoke Secret Server's access to that external key at any time. Doing so immediately renders all secrets unusable, cutting off any further decryption. This includes any decryption that might be attempted to comply with a CLOUD Act order.

This is a documented, available functionality today. It is a lever that sits entirely outside Delinea's control or cooperation. The customer doesn't have to trust Delinea's process, because the ability to cut off access is architecturally theirs alone.

What should I do next?

Three concrete steps you can take today:

1. If you're running an on-premises vault today, move your Master Encryption Key (MEK) into an HSM first. This is the single highest leverage move available that's already supported. It takes your key out of a software-based key store and into a separately administered hardware boundary, the first real step off of Tier 1.

2. Install Server Suite privileged access controls to lock down the infrastructure around the vault. An HSM protects the key, but the vault still runs on a host that needs the same discipline you'd apply to a physical safe: bolting it to the floor, adding motion detection, seismic detection, and a camera watching it.
   
   Server Suite is that layer for your servers offering: zone-based delegated access controls, MFA enforcement, privilege elevation, and session control on the OS underneath the vault with separate administrative zones for the OS, Database, MQ and distributed engines. Now, a compromised host or role isn't a straight line to the key material.

3. Move your vaulted secrets to Delinea Platform and Secret Server Cloud. This is the institutional-depository tier with: independent audits, continuous 24/7 operational monitoring, and a dedicated team tracking software component updates. You'll also get the post-quantum migration timeline across the whole customer base at once, a level of assurance that isn't a purchase decision for a single customer; it's a scale business we run so you don't have to build it yourself.

Every tier on this ladder is a real, legitimate choice. The mistake is assuming the top of what a customer can build alone is the same as the top of what's achievable. It isn't.

The best home safe is genuinely good; the best private vault a customer can build is genuinely excellent; but the institutional depository tier exists because independent audit and continuous operational depth are things an organization builds once and runs at scale for every customer. It’s not something any single customer, however well-resourced, can stand up alone.

Quickly secure every privileged account

Try a full-featured enterprise-grade vault that takes security, efficiency, and usability to the next level.

VIEW DEMOS