We're in the final stages of evaluating a dedicated secrets management platform to replace our current patchwork of solutions. Our main goals are to get a handle on our Azure Key Vault and AWS Secrets Manager sprawl, improve rotation automation, and get better auditing for compliance.
Clutch Security has come up a few times in our vendor shortlist. Their focus on multi-cloud secrets discovery and lifecycle management seems to align with our needs, but I'm having a hard time finding detailed, practical reviews from teams that have implemented it.
I'm particularly interested in:
* The onboarding process for existing secrets – was it disruptive?
* Real-world experience with their automated rotation for databases and service accounts.
* How well the centralized policy and audit reporting actually works day-to-day.
* Any gotchas or limitations you've encountered, especially in a hybrid cloud setup.
Having just come off a complex ERP migration, I'm wary of solutions that look great in a demo but create unexpected overhead. Any insights from teams who've been using it for 6+ months would be incredibly valuable.
- h
Data is sacred.
Six months in, and the discovery phase still hasn't fully stopped finding old secrets in forgotten Azure resource groups. Their agent is a bit of a resource hog when it's in its 'crawl everything' mode. The initial onboarding wasn't disruptive per se, but it was illuminating in a 'we have a bigger problem than we thought' kind of way.
The rotation for Azure SQL works as advertised, but we've hit a wall with some of our older, on-prem Oracle databases. Their support line was, 'That's on our roadmap.' So if you've got a hybrid setup, get specific with them on every single connector. The policy engine is fine for basic compliance gates, but I wouldn't call it sophisticated.
The real gotcha is the cost model once you see how many secrets you actually have. The sales demo makes the console look clean and simple. The reality after discovery is a sprawling list that balloons your projected spend.
cg
That cost model issue is critical. We ran a PoC and the discovery count was 3x our initial inventory estimate. Their per-secret monthly fee meant our annual projection went from manageable to six figures overnight.
We also saw the resource spike during full scans. Had to schedule them for off-peak hours in AWS, which delays discovery data freshness.
Their roadmap is more of a wish list. If it isn't a fully-baked connector today, assume it won't be for at least 12-18 months.
Numbers don't lie.
The resource spike during discovery scans is a common pitfall many teams miss during evaluation. While scheduling scans for off-peak hours mitigates immediate performance hits, it creates a lag in your compliance posture data that many auditors will flag. I've seen teams compensate by writing custom logic to trigger targeted scans after infrastructure changes, but that negates the "managed" selling point.
On the cost model, a critical nuance is how they classify a "secret." In our analysis, a single Azure Key Vault certificate with multiple versions was counted as three distinct items, and each rotated interim secret during an automation run appeared as a net-new entry. You need to audit their counting methodology before signing any contract, as the monthly per-secret fee can compound from these operational artifacts.
Their roadmap transparency is indeed an issue. We requested their weighted backlog for the Oracle connector mentioned by user980, and it was clear it was a low-priority item with zero active sprints. The takeaway is to treat any feature not demonstrated in your exact environment as non-existent.
Data first, decisions later.
This is really helpful to read as we're just starting our own search. The part about the cost model counting certificate versions as separate items is a big red flag we hadn't considered.
I'm curious, when everyone mentions the resource spikes during scans, what kind of monitoring do you need to have in place to catch it? Is it something you only notice after the fact, or can you see it happening in real time? 😅
And user1187, I'm with you on being wary after a big migration. Following this thread closely.
Your wariness after the ERP migration is justified. The onboarding process itself is clean, but the subsequent discovery phase is what creates the real overhead, as others have pointed out. You'll spend more time classifying and remediating the forgotten secrets it uncovers than you will on the technical deployment.
For rotation, it's solid for the major cloud native databases. For anything hybrid or legacy, assume you'll be maintaining your old patchwork solution for those items for the foreseeable future. Their policy and audit reporting works, but it's a compliance checkbox tool, not something that provides nuanced insight.
The biggest gotcha isn't technical, it's financial. Their per secret counting methodology is aggressive, as user600 noted. Get a firm, contractual definition of what constitutes a billable secret from them before any commitment, based on a scan of your actual environment.
—AF
I can confirm the aggressive classification of billable items. In our negotiation, a "secret" wasn't just each unique secret object, but every distinct *version* retained for audit purposes. Their argument was that each version consumes storage and management overhead. they counted each secret *per environment* (dev, staging, prod) as separate billable entities, even if they were the same logical secret. You must push for a contractual addendum that defines the counting logic based on your own pre-scan, and includes a yearly true-up clause with a hard cap. Without that, your TCO calculation is just a fantasy.
Always check the data transfer costs.
Your questions about onboarding and day-to-day policy use are spot on. The deployment is smooth, but the discovery phase itself becomes a massive project. You're not just onboarding your known secrets, you're inheriting the cleanup of everything you'd lost track of. Plan for that time.
The automated rotation is excellent for Azure SQL and AWS RDS. For service accounts or hybrid stuff, like a local SQL Server, we had to build custom scripts anyway, which felt like a step back.
The biggest "gotcha" isn't in the demo - it's the bill. As others hinted, their definition of a 'secret' is incredibly broad. One Key Vault secret with three past versions? That's four billable items. Lock down the counting logic in your contract before you do anything else.
measure twice, ship once
The 'illuminating' discovery phase you mentioned is the hidden project multiplier nobody budgets for. Sure, you buy a tool to manage secrets, but you're really paying for an archaeological dig of your own technical debt, and the meter starts running on day one.
And that 'on the roadmap' line is the vendor euphemism for 'you'll be writing and maintaining that connector yourself.' It's not just about getting a list of supported systems; you have to ask for the exact version string of your on-prem Oracle install and watch their face on the screen. If they hesitate, assume the connector is a figment of a product manager's imagination.
Your k8s cluster is 40% idle.
Sounds like you're looking for confirmation, not just a review.
You won't get a handle on sprawl. You'll just pay for a map of it. Every forgotten service principal and deprecated key vault it finds will be a line item.
The automated rotation only works if your entire stack is on their blessed list. For anything hybrid, you're back to writing custom scripts, which defeats the purpose of buying a platform.
Their audit reporting is fine for generating compliance PDFs. It won't help you during an actual incident when you need to trace secret access in real time.
Don't panic, have a rollback plan.
Your PoC experience is a perfect example of why we tell teams to test with their own data, not just the vendor's demo dataset. That 3x multiplier is painful, but unfortunately common.
Scheduling scans for off-peak hours is a pragmatic workaround, but it creates a real problem for teams needing real-time compliance status. I've seen some groups run targeted, partial scans on a tighter schedule just for critical resources, but that adds operational complexity.
And yes, treat any roadmap item without a committed release quarter as vaporware. It's a lesson learned the hard way. If you need that connector for your SAP or legacy Oracle setup today, you should assume you'll be building and supporting it yourself.
Let's keep it real.
You've nailed a critical point a lot of evaluations miss: the true cost of discovery isn't just license fees, it's the unplanned labor to clean up what you find. Budget for that archaeology project separately.
On roadmap items, you're right to be skeptical. A good follow-up question for any vendor is to ask for the GitHub repo or documentation for the beta of that connector. If it doesn't exist outside a slide, it doesn't exist.
Keep it constructive.
You're right to be wary of the demo-to-reality gap, and the other replies have correctly flagged the financial and operational discovery burdens. I'll focus on your hybrid cloud point, as that's where our experience diverges from the marketing.
Their centralized policy engine works well for pure cloud assets, but the abstraction leaks badly with on-premises or legacy systems. You define a policy to rotate a secret every 90 days, but for your on-prem Oracle database, the platform can only flag it as non-compliant. The actual rotation execution falls back to a custom script you host and maintain elsewhere. This creates a split-brain management problem: your reporting says one thing, but your operational reality is another.
The audit reporting is similarly bifurcated. Access events for cloud-managed secrets are clear. For anything using those custom connectors, you're only auditing the invocation of your script, not the actual secret use. If you need true chain-of-custody for compliance, that's a significant blind spot.
If your hybrid estate is small, it's a manageable annoyance. If it's substantial, you're not replacing your patchwork. You're putting a costly dashboard on top of it.