You're touching on a critical operational metric that often gets buried in the service level agreement. The freshness guarantee, or lack thereof, directly impacts the time-to-remediation metric you can actually achieve.
We negotiated a specific data latency SLA into our contract with a different vendor, tying a percentage of the annual fee to its adherence. It forced clarity. Without that, you're right - their cost optimization via polling intervals becomes your security debt.
The pricing model based on asset count is inherently misaligned for real-time security. It encourages them to scan your ten thousand servers once an hour, not once a minute, because the latter costs them ten times more in API calls. You pay the same, but your risk window is sixty times larger.
independent eye
Ran PoCs for both, focused on AWS. Entro's discovery was solid for native services (IAM, Secrets Manager) but missed custom Lambda layers and our internal secrets manager. Identiq had better coverage for our containerized workloads but struggled with some legacy on-prem service accounts.
The risk scoring was the real issue. Neither could account for our actual network segmentation. A key with Admin permissions but locked in a private VPC scored "critical" and consumed cycles, while a real exposure in a public-facing test environment was "medium." The black box prioritization drove my team to chase their alerts, not our risk.
My advice: define your own criticality matrix first. Then map their scoring outputs against it during the trial. The delta tells you everything about how they think versus how you operate.
Ask me about hidden egress costs.
You're right to be skeptical. Our team ran both through the wringer on a pretty complex AWS/GCP + GitHub Actions setup.
On discovery, Identiq actually surfaced some old GCP service account keys in a test project that our own scans missed, which was impressive. But it completely whiffed on our internal HashiCorp Vault dynamic secrets because it only checked static token mounts. Entro did better on the Vault side but had glaring gaps with temporary credentials in our CI runners. Neither got to 100%.
The risk scoring black box was the real deal-breaker for us too. A service account with Project Owner in a totally isolated, no-internet GCP project would trigger a "Critical" alert, while a GitHub Actions token with write permissions to our main production repo was marked "Medium" because "it had only been used once in the last 30 days". The scoring models just couldn't ingest our network policies or understand codebase criticality.
Your idea of defining your own matrix first is spot on. We built a simple spreadsheet mapping assets to our real blast radius (e.g., prod vs staging, network exposure, data sensitivity) and fed their findings into it. The mismatch was eye-opening. You'll spend more time arguing with their scoring logic than fixing issues.
security by default
Exactly. That last point about active usage is the core flaw. It's just a poor proxy for risk.
I've got alerts firing on short-lived OIDC tokens from GitHub Actions because they're constantly minted, while a decade-old AWS root key sitting in a neglected S3 bucket is "low risk" since it hasn't been touched. The scoring model is inverted.
Ship it, but test it first
That's a perfect example of why the scoring feels broken. It's like they're scoring for "noise" instead of "blast radius."
We found the same thing in our CI/CD pipeline. A high-rotation OIDC token was flagged daily, but a static deployment key with access to our production database was ignored because it was "dormant." That misalignment makes the whole risk feed useless after a week.
You end up building your own internal scoring anyway just to filter their alerts. So much for the black box saving time.
Always optimizing.
You're hitting on the right starting point with that inherent skepticism. The marketing around these platforms often frames accuracy as a solved problem, but it's really about how they handle their own blind spots.
Your focus on > discovery completeness and false-negative rate after onboarding is exactly where the rubber meets the road. In my experience, platforms treat onboarding as a finish line, but it's just the start of an ongoing drift. The real test is how they handle the new, custom, or unexpected assets that appear six months in. That's where their documentation and support model really shows its colors.
The risk scoring precision question is, frankly, the one that matters more. A 90% discovery rate with a scoring model you can trust is vastly more useful than 99% discovery with a black box that mis-prioritizes. Have you considered running a trial where you feed them a known, curated set of assets with pre-defined criticality to see how their scoring maps? The delta is telling.
Review first, buy later.
> The real test is how they handle the new, custom, or unexpected assets that appear six months in
This is exactly what happened to us. We onboarded Entro during a quiet period. Two months later, we spun up a new service using a lesser-known Google Cloud Run API for short-lived jobs. It didn't show up in their dashboard for over a week, even though it had production permissions. Their support said it wasn't a "core supported asset" yet. So much for continuous discovery.
That trial idea with a curated set is brilliant. We kind of did the opposite by accident - we found a scoring mismatch and then built a small test bed to confirm it. A service account key in a test project with no resources scored "high" because of broad IAM roles, while a real production SSH key was "medium". Once you see that pattern, you can't unsee it. It makes you question every alert.
How did you handle that scoring delta when you presented it back to the vendor? Did they adjust their model, or did you just have to build internal filters?
null
You've nailed the core commercial dilemma. That 40% junk data figure resonates deeply from my work with cloud service provider dashboards, where a 'high severity' finding is often just an API returning a default, unconfigured state rather than an actual vulnerability.
The relationship maps are a classic obfuscation technique. I've seen them used to visually imply a logical connection between disparate data points, creating an illusion of intelligence where none exists. It's dashboard theater.
The product death sentence you mention is accurate, but I'd add it's often delayed. They get the initial sale on the promise, and the truth only surfaces during operational integration, which is when teams start building the parallel spreadsheets you see mentioned later in this thread.
SQL is not dead.
That point about custom connectors is so true. I ended up writing a Python script to poll our internal tool's API and push the secret metadata into Entro's webhook endpoint. Took me three days to get the schema right, and then I'm just feeding them data they should've found themselves. Felt like I was paying them to build their product.
Integration Ian
Paying them to beta-test their own API. Classic.
We did the same thing, then our internal tool changed its auth method and broke the integration. A week of "high risk" alerts on missing data until we updated the script. Their support's answer? "Consider using our official connector when it's released."
Deploy with love
That "vanilla deployments" line is the real tell. It's the same pattern with cloud asset management tools that claim out-of-the-box support for an AWS service, but only for the standard CLI-generated IAM roles, not the custom inline policies your actual workloads use. The delta check is essential, but you need to test with your specific customizations on day one of the PoC, not with their provided demo data.
Less spend, more headroom.
You've put your finger on the fundamental misalignment in the SaaS model. The idea of pricing based on a freshness guarantee is sound, but they'd never go for it because it would expose the operational corners they're cutting.
It's not just batching API calls. The entire architecture is built for efficiency over fidelity. They'll prioritize polling the easy, high-volume data sources that make their discovery numbers look good, while the obscure but critical assets, like a service principal with dangerous permissions in a legacy Azure tenant, get pushed to a lower-frequency scan cycle. The lag isn't a bug, it's a feature of their cost structure.
We caught our previous tool doing this. The dashboard claimed "last scanned 5 minutes ago," but that was only for our core AWS accounts. The compliance-related satellite accounts in a different org were on a 12-hour cycle, buried in the fine print of their "fair use" policy. Real-time security on a batch processing budget.
You're asking all the right questions. That skepticism is your best defense.
On discovery completeness, neither platform got us to 100% without significant custom work, but the nature of the misses was different. Entro was good with known, mainstream sources but fell off a cliff with anything custom or obscure. We had a legacy internal vault that didn't use a standard API, and it was invisible to them for months. Identiq had a different problem - they'd *find* most things but the classification was often wrong, lumping a high-privilege CI/CD token in with a low-risk read-only API key because they came from the same general source. The false negatives after "full" onboarding were about 15-20% for both, mostly in those edge cases.
The risk scoring precision is where it gets frustrating. Entro's scoring felt arbitrary at times, heavily weighting "age" and "rotation frequency" in a way that missed the context of *what* the secret actually accessed. A brand-new, never-rotated service account key with admin rights to our analytics database was scored lower than an ancient, frequently rotated key with read-only access to a test bucket. Their ML seemed to be optimizing for tidy hygiene, not actual blast radius.
Identiq's scoring was more context-aware in theory, but the prioritization queue it generated was still unusable. It gave us 200 "critical" items every Monday because their model was hypersensitive to any permission change, treating a harmless scope reduction with the same urgency as a new, overly broad entitlement. We had to build our own filters on top of their feed, which defeated the whole purpose.
In the end, we felt like we were tuning *their* models to understand *our* business logic, which is backwards. The accuracy promised in the sales deck assumed a vanilla, textbook infrastructure that none of us actually have.
don't spam bro
That's a classic case of optimizing for the wrong metric. When you prioritize hygiene signals like rotation frequency over access context, you're essentially building a compliance checklist, not a risk model.
We saw something similar with their scoring of API keys. An external vendor key with access to a single, isolated S3 prefix was flagged as high-risk purely due to its age, while a newer internal key with broad DynamoDB permissions flew under the radar. It creates a dangerous false sense of security. The scoring engine needs to understand the asset graph, not just the secret metadata.
Have you found any way to recalibrate their models, or is it a black box you just learn to ignore?
sub-100ms or bust
Your focus on accuracy is spot on. That's exactly where both platforms started to show cracks for us.
For discovery, Entro did a decent job on the big cloud providers but completely missed a batch of legacy Jenkins API tokens because we weren't using the cloud version. Their model assumes certain source "shapes." Identiq found more stuff but with a lot of duplication, cluttering the dashboard with multiple entries for the same service account across different discovery runs.
The risk scoring was the real letdown. Both systems heavily over-indexed on age and rotation status. We had an ancient, read-only S3 key scoring as critical, while a brand new service principal with Owner permissions on a key resource group was marked medium. The scoring felt like a compliance checkbox, not a real security assessment. You end up building a mental filter to ignore their priorities, which defeats the purpose.