I'm currently leading a PAM consolidation and Identity Threat Detection & Response (ITDR) initiative for a multi-cloud fintech environment (AWS, GCP, Azure, plus on-prem legacy). We are in the final stages of vendor evaluation and have shortlisted **Entro Security** and **Glide Identity** for their respective, seemingly complementary, strengths. The stated use cases are distinct—Entro for secrets management and non-human identity lifecycle/sprawl control, Glide for human JIT access and granular privilege elevation workflows—but there is significant functional overlap in the broader "identity security" and "privileged access" space.
My team's initial PoC analysis indicates potential integration points, but also areas of conflict or redundancy we need to architecturally resolve *before* procurement. I'm seeking insights from anyone operating both platforms in production, particularly regarding:
* **Orchestration Layer:** Do you use a third-party orchestrator (e.g., custom scripts via Terraform/Ansible, a SOAR platform) to manage the handoff between Entro's discovery/classification of identities and Glide's access governance? Or do you rely on native APIs from one into the other? A concrete example of a workflow would be invaluable.
* **Source of Truth Conflicts:** Entro maintains its own inventory and risk scoring. Glide has its own directory sync and policy engine. How do you handle identity attribute synchronization to avoid drift? Which system ultimately "owns" the risk score that triggers a JIT or break-glass workflow?
* **Performance & Observability Overhead:** Both platforms require agents, API integrations, and periodic scanning. In a large-scale environment (>10k cloud accounts, >50k identities), what has been the observed impact on IAM latency (e.g., AWS IAM GetRolePolicy calls, Azure AD Graph queries)? Have you needed to implement specific queuing or throttling?
* **Unified Reporting:** How are you combining findings (e.g., Entro's secrets leak detection with Glide's session audit logs) for compliance (SOC2, PCI DSS 4.0) evidence? Are you funneling logs to a central SIEM and correlating there, or using one platform's dashboard as the primary?
Our preliminary benchmark data from the PoC (using a simulated workload of 5000 identities) shows the following latency in milliseconds for a complete "detect-to-remediate" cycle:
```
Workflow: Detect new AWS IAM Role -> Classify Risk -> Provision JIT Access in Glide.
| Step | Entro Solo | Glide Solo | Entro+Glide (Naïve API) | Entro+Glide (Orchestrated) |
|-------------------------------|-------------|------------|--------------------------|----------------------------|
| Discovery & Classification | 345 ms | N/A | 350 ms | 340 ms |
| Policy Decision & Approval | N/A | 420 ms | 850 ms (serial call) | 430 ms (parallel) |
| Access Provisioning | N/A | 210 ms | 220 ms | 215 ms |
| **Total Cycle Time** | **345 ms** | **630 ms** | **1420 ms** | **985 ms** |
```
The "naïve" integration added significant latency, which we aim to mitigate. Any real-world data points or architectural diagrams you can share would be immensely helpful for our final design review.
— jackk, MS in CS
Test it yourself.
Your point about orchestrating the handoff is crucial. In our deployment, we found the native APIs insufficient for the complex lifecycle events we needed to model, particularly for service accounts discovered by Entro that then required governed access via Glide.
We built a lightweight middleware using AWS Step Functions and a bit of Lambda code. It listens to Entro's webhooks for a new high-risk non-human identity, enriches the data with our own CMDB tags, and then uses Glide's API to automatically create a corresponding access package with JIT rules. Trying to make one platform the primary orchestrator for the other created too many dependencies.
The key was defining a clear ownership boundary: Entro owns discovery, classification, and the alert on a non-human identity's creation or misconfiguration. Glide owns the subsequent access policy and workflow for *any* principal, human or not, that needs elevation. The middleware just passes the baton.
independent eye