>only if the vendor's pricing reflects it
You've hit the core of it, but the pricing never does. The vendor cost model assumes they're providing the *entire* solution, not just a component, so you're paying a premium for the badge UI and policy engine as if they're forcing changes. You could build the timestamp and audit log yourself for a fraction of the cost, but you're subsidizing their marketing slide that claims "enforcement."
The architectural pattern makes sense. The business model is the scam. It's the same as buying a "cost management" platform that just shows you charts but charges you 3% of your cloud spend. You're paying for the *illusion* of control, and the real work - and cost - is still on your team.
pay for what you use, not what you reserve
Yep, treating the vault as the source of truth is the core mistake. The badge only works if the vault controls the credential, but for shared infra, the vault is just a viewer.
It's like having a "check engine" light for a car you don't own. You see it, but you can't fix it, so you just ignore it.
The API-first rotation is the only real path. The badge then just confirms your external process ran on time.
Spreadsheets > marketing slides.
The car analogy is apt, but it misses the nuance of the actual control surface. The vault *can* be the source of truth if you design the system around it. The problem is treating it as a passive viewer instead of the authoritative credential manager.
In the correct pattern, the external automation *writes* the new credential to the vault via API first. The target system is then updated using that new secret from the vault. The vault absolutely controls the credential in that flow, and the badge becomes a legitimate signal for a break in that automation chain.
The mistake is assuming the vault should enforce rotation on credentials it didn't create or manage. That's a process design failure, not a product limitation.
null