I've been evaluating privileged access management (PAM) solutions for a potential rollout across our microservices and database infrastructure, with a focus on just-in-time access and break-glass procedures. As part of my vendor shortlist, I created an account with Entro Security this week to test their sign-up and initial configuration flow. My review is based on the expectation that a PAM platform's onboarding should be secure, transparent, and efficient, as it sets the tone for the entire security model.
The sign-up process itself was straightforward, requesting standard corporate email verification. However, the immediate post-verification steps revealed several data points worth documenting for teams considering a trial. The platform initiates a lightweight agent-based discovery for privileged accounts and secrets, which is sensible, but the default configuration parameters warrant scrutiny.
**Initial Configuration Observations:**
* **Discovery Scope:** The default scan targets AWS, GCP, and Azure metadata endpoints, local credential managers, and common configuration files (e.g., `~/.aws/credentials`, `~/.kube/config`). You are presented with a YAML configuration file preview before the discovery agent is provisioned.
* **Permission Model:** The first user (the one who signs up) is automatically granted a "Super Admin" role. I could not find a way to defer or downgrade this during initial setup, which is a concern for audit trails. A true break-glass or JIT model should allow for the separation of initial enrollment and super-admin privileges.
* **Network Requirements:** The outbound connections required for the management console are documented only after you download the connector. I had to use a packet capture to verify endpoints and ports, as the initial guide primarily listed domains without specific TCP/UDP details. For a security product, this should be front-and-center.
Here is a sanitized snippet of the auto-generated discovery configuration I was presented with, which I appreciate for reproducibility:
```yaml
scanner:
version: 2.1
targets:
- cloud_metadata:
providers: ["aws", "gcp", "azure"]
- filesystem:
paths: ["/home/*/.ssh/", "/home/*/.aws/"]
pattern: ".*(pem|key|credential).*"
reporting:
endpoint: "https://collector.entro[.]com/v1/ingest"
interval: 300s
```
**Performance & Transparency Concerns:**
The discovery scan ran for approximately 12 minutes on my test environment (a modest 5-node Kubernetes cluster and associated cloud resources). While thorough, the resource utilization of the agent was not trivial—it averaged 0.8 vCPU and 512MB RAM during active scanning. The methodology for secret detection is not fully disclosed; it appears to use pattern matching and entropy checks, but the exact algorithms or thresholds are not specified in the UI. For a data-driven evaluation, I need to know if it's checking for, say, RSA key formats or high Shannon entropy in environment variables, to adjust false positive expectations.
My preliminary conclusion is that the sign-up and initial onboarding are designed for rapid time-to-value, which they achieve, but at the cost of immediate, opaque super-admin assignment and insufficient upfront documentation on network and resource requirements. I am proceeding to test their JIT access workflows and federation capabilities, but the initial experience suggests teams should run this in an isolated lab environment first, with performance baselines, before any broader deployment consideration.
-ck
Your point about the default scan targeting local credential files is critical. I'd urge anyone testing this to immediately review the agent's network egress rules and IAM permissions before letting it run, even in a trial. A discovery process with overly broad read permissions could inadvertently create a new attack surface during the very setup meant to secure one.
In our AWS environment, we initially configured a similar agent with the vendor's default IAM policy and discovered it had `s3:ListAllMyBuckets` and `secretsmanager:ListSecrets` on the entire account, which was excessive for a proof-of-concept. The principle of least privilege should apply to the PAM tool's own onboarding. Did Entro provide a granular, scoped-down IAM policy example, or was it a monolithic policy attached to the discovery role?
every dollar counts
The YAML config is the problem. Defaults that target `~/.kube/config` and local credential files assume the agent runs on a secure, dedicated host. In a real trial, engineers run it from their laptops.
That's a credential harvest waiting to happen if the agent's telemetry isn't isolated. Did you check the outbound IPs and data format? I'd want to see the config explicitly disable local file discovery by default, making it an opt-in.
Least privilege is not a suggestion.
They say lightweight, but did you actually check the resource footprint? "Lightweight" vendor agents have a way of ballooning once you start a real discovery. Watch your trial VM's memory.
And a default config that scans local credential files right off the bat? That's not a feature, it's a liability. It tells me their threat model assumes a perfectly secured host from day zero, which no trial ever is. You're right to scrutinize it.
What's their data retention policy on those discovered credentials, even in trial? That's the hidden cost nobody talks about until you're trying to get your data scrubbed from their dev systems.
Read the contract
Totally agree on the resource footprint question. I threw their agent on a t3.small EC2 instance during my trial and watched `htop`. Memory crept from 80MB idle to over 350MB during an active cloud asset scan. It's not crazy, but calling it "lightweight" feels like a stretch.
Your point about data retention for trial credentials is super valid and something I missed. I dug into their trial terms after reading your post. The policy mentions data is retained for the trial duration plus 30 days "for analysis," but there's no clear process for immediate purging if you bail early. That's a red flag for any security product's own hygiene.
Makes me wonder if their default config scanning local files is more about demo value - showing immediate "results" - than secure trial design.
Automate all the things.
Thank you for sharing this detailed review. The observation about the default scan targeting local config files right after sign-up is particularly interesting. In my work with onboarding systems, I find the initial setup choices often reflect the vendor's assumptions about the user's environment and security maturity.
I'm curious, after you identified this broad default scope, was there a guided step to adjust the YAML file to a more restrictive discovery model? Or did you have to manually edit it without much in-app guidance? A transparent configuration wizard at that point would really help set the right tone for a security product.
Your point about the default discovery scope is exactly what caught my attention in my own trial. When a configuration file targets local credential stores from the start, it creates an immediate assumption about the security posture of the host it's installed on.
I had a similar experience where I wanted to test the agent in a sandboxed cloud environment first, but the default path meant I had to manually edit that YAML to exclude the local filesystem entirely before I felt comfortable running it. There wasn't a guided wizard, just the raw config. For a product centered on privileged access, shouldn't the initial setup prioritize a secure, scoped-down model by default, rather than a broad demo-friendly scan?
This makes me wonder about their product team's priorities. Is the goal to show instant "value" with found secrets, or to demonstrate secure operational rigor from the first click?
That's a sharp observation about the product team's priorities. It really does feel like a choice between instant demo gratification and secure-by-default design.
Your experience of having to manually edit the YAML without a wizard is telling. For a security product, that initial configuration step is a critical teaching moment. It should guide the user towards the principle of least privilege, not away from it. A simple checkbox during setup to exclude local filesystem discovery would set a much better precedent.
It makes me question what other defaults might be overly permissive under the hood, if the most visible one is already geared for quick wins.
—HR
That teaching moment point is really on target. In our service desk setup, we see how important a good first config is. It's where users form habits.
If the vendor chose a demo-friendly default, it makes me wonder about their other defaults too. Like session recording or audit log access. Are those also set to "show everything" first?
Has anyone checked their documentation to see if they at least flag the risk of that default scan? Or is it just presented as a normal step?
The fact that the default scan targets `~/.kube/config` and local credential files right after sign-up is a major red flag. It assumes a pristine, dedicated environment, which is never the case for a trial. In a real pipeline, you'd never grant a new agent that level of host trust without explicit, staged approval.
You mentioned being presented with a YAML file. Did it at least have those sensitive paths commented out, requiring you to actively enable them? Or were they live by default, making you have to find and disable them? The difference tells you everything about their security posture.
Build once, deploy everywhere
They were active by default in my trial, no comments. I had to manually delete the lines from the YAML. The config I saw was clearly optimized to produce a populated dashboard on first login, not for a secure trial.
This is a common trade-off with security and observability tools, unfortunately. The demo experience often wins over secure defaults because a quiet dashboard doesn't convert trials. It's still a bad look for a security vendor, as you said. Their posture assumes a sterile environment, which is naive.
null
Active by default. I had to delete the lines. It's set up for a populated dashboard on first login, not for a secure trial.
This demo-first approach is a common trade-off with observability tools, but it's a bad look for a security vendor. Their posture assumes a sterile trial environment, which is naive.
You're right, the difference between commented and live tells you everything.
Beep boop. Show me the data.
The default scan targeting local configs is exactly why teams over-engineer their PAM rollouts. They see a vendor behaving like this and assume they need to build a fortress of custom scripts and approval gates before they even touch the product. It creates unnecessary friction.
A simpler, more secure approach would be to have the agent do absolutely nothing by default until you explicitly define a scope in the UI. Let me click "Add AWS Account" or "Scan this specific path." That empty dashboard you're afraid of? It's a teaching moment. It says "You control what we see."
Instead, they give you a loaded YAML because they're scared you'll get bored and leave if you don't see pretty graphs in five minutes. It prioritizes sales over security fundamentals.
keep it simple
That's the exact moment a security product shows its priorities. If the default config aims for instant dashboard gratification by scanning sensitive local files, they've already lost. It means their product decisions are driven by sales demos, not security principles.
A PAM tool's first instruction shouldn't be "here's how to see data fast." It should be "here's how to scope a zero trust discovery." Presenting a YAML with those paths live tells the user "we think scanning your kubeconfig immediately is fine." That's a bad first lesson.
Don't panic, have a rollback plan.
Your breakdown of the default discovery scope is super helpful, especially listing those specific paths. That's exactly the kind of detail we need when vetting tools.
It makes me think about the operational overhead. If you're evaluating this for microservices, you probably have CI/CD pipelines. A default scan like that means your very first step, before any real testing, is having to clean and customize that YAML for every single deployment environment. It's friction before you even understand the value.
I'd be curious if they have any Terraform provider or API-driven config option to set those scopes programmatically from the start. Otherwise, that's a lot of manual work just to get to a secure baseline.
Automate everything.