•
What keeps us up at night here at Opal? The fact that security teams are still flying blind when it comes to identity. If security teams were truly empowered to solve and manage identity crises, we wouldn’t keep seeing the same breaches play out again and again. Yet here we are: stolen credentials, overprovisioned third-party vendors, API keys sitting forgotten in repos, and service accounts no one remembers creating remain the status quo. Worst of all, security teams are stuck reacting to the fallout – but they don’t have the power to prevent any of it in the first place.
We talk to CISOs and security practitioners daily, and these themes keep coming up. They know identity is almost definitely their broadest, fastest-growing attack surface. They know attackers don’t care whether they compromise a human or machine identity. They know their teams are responsible for cleaning up the mess when things go wrong. The issue is, security teams still don’t control identity. It’s scattered:
Human identities? That’s IT’s problem (managed through IDPs, static roles, and slow approval workflows)
Machine identities? That’s DevOps’ problem (buried in Terraform, cloud IAM policies, and scattered service accounts)
Security teams? They get the blame when an attacker finds the gaps (naturally)
Agents? We’re about to find out!
This fragmentation is why identity remains the top attack vector year after year. Security teams don’t just need visibility into identity risk: they need control over it.
Why identity governance isn’t enough
Most companies already have an identity governance tool in place – but most also overlook (or discount) the fact that governance isn’t security. Here’s why:
Quarterly access reviews don’t stop real-time attacks: By the time you flag excessive permissions, an attacker may have already exploited them.
RBAC can’t keep up with cloud environments: Static roles don’t work when identities and workloads are changing by the minute.
Workflows don’t solve security problems: If security teams still need IT or DevOps to make identity changes – and if their tech stack and architecture can’t even support those changes with the automation, speed, and scale required to meaningfully reduce risk – then nothing is actually being fixed.
Some vendors claim to “unify” identity security across human and machine identities. But most of these solutions still operate like traditional governance tools – requiring IT workflows, relying on static roles, and failing to enforce real-time security controls. Security teams don’t need another dashboard telling them what’s wrong. They need the power to fix it!
Why security needs to own identity risk
For identity security to actually work, security teams need:
Just-in-time access as the first building block: Users and service accounts should only have access when they need it (and lose it when they don’t). Implementing JIT is an ideal – and arguably even elegant – step one because it’s frictionless yet still puts a big dent in identity risk.
The ability to enforce least privilege themselves: No more waiting on IT tickets or DevOps approval chains – and no more assuming least privilege just means enforcing the absolute minimum amount of access (which is neither feasible nor ideal for most). Instead, it’s about enabling rightsized access for the right entities to the right systems.
An actually unified approach to human and machine identities: After all, attackers don’t care whether they’re compromising an engineer’s SSO session or a cloud service account.
The industry talks a lot about visibility. But, our experience here at Opal is that visibility without enforcement is just an audit report waiting to happen.
Why we built Opal
We built Opal because security teams shouldn’t just report on identity risk; they should be able to nearly eliminate it. Opal makes that possible by giving security teams the control they need but have never had:
Direct security ownership over access for all identities: No more dependency on IT or DevOps workflows, and no more siloes across human and machine identities.
Just-in-time and “use it or lose it” access that replaces standing privileges: No more excessive permissions hanging around indefinitely.
Deep, native integrations that help protect the crown jewels: No more disjointed visibility and control over access to business-critical assets. Enforce least privilege in real-time for the cloud (e.g. at the IAM level in AWS, GCP, Azure, and more) and across first-class data systems like Snowflake and Databricks.
Terraform & CLI support that enables infrastructure as code: Identity security and IAM workflows that can be programmatically set up and maintained through code is all built-in to DevOps workflows – not bolted on after the fact.
A flexible API and vast ecosystem that ensure coverage enterprise-wide: Secure access not only to systems behind an IDP or cloud – but also to everything else (even sensitive internal tools and apps without SCIM support).
Deployment on your terms – SaaS, self-hosted, or even air-gapped: No more compromises or workarounds. Whether you're cloud-first, managing on-prem infrastructure, or operating in a highly regulated environment, Opal fits seamlessly into your stack without sacrificing security or control.
In other words, Opal is not another governance tool. We provide security for every identity – and we’re built specifically for security teams who are tired of waiting for someone else to fix the problem.
It’s time for security teams to take control
If you’re still waiting for IT to make access changes, if your identity security strategy consists of quarterly reviews and hope, if you can’t answer who or what has access to your most critical systems right now – then you don’t control identity security. And if you don’t control it, you can’t secure it (and you’re already behind). Security teams, consider this your call to action. Click here to see how Opal works.
Acknowledgements
Special thanks to Product Manager Shelley Wu, Software Engineer Murad Akhundov, Software Engineer Andrew Sy, Product Lead Grant Empey, and CEO Umaimah Khan for their contributions to this blog.
