Identity management is harder than it should be

Our thinking on identity hasn't evolved in a long time. The predominant access control model of Role-Based Access Controls (RBAC) was developed in the 1990s, while the more modern alternative of Attribute-Based Access Control (ABAC) is already a decade old. We're having the same conversations now we've been having for years: Should access be granted on demand? How should you manage service account identities? What happens when someone's manager changes? Most organizations still struggle to implement sane access controls.

The problem isn't missing frameworks or standards. We have plenty of those. The problem is that identity management in practice looks nothing like identity management in theory.

Identity should be simple

Most organizations aim for a reasonable approach that should, in theory, ensure only authenticated and authorized users can access resources: authenticate using SSO through an identity provider, ideally with hardware-backed MFA, and sync users and groups with SCIM provisioning. When fully implemented, these controls work well. The challenge is that any gaps in coverage — whether it's legacy applications that don't support SSO or SCIM, incomplete SAML logouts, or weak MFA — create openings that attackers consistently exploit. Groups like LAPSUS$ have taken advantage of these gaps again and again. Which is to say, these controls don't work in reality.

We don't live in a world where every application supports these standards. Critical apps like Stripe only support SSO in beta and don't support SCIM at all. Snowflake didn't require MFA until recently. Forget social media accounts — getting to 100% coverage is nearly impossible when even security-conscious SaaS providers aren't there yet.

SaaS has grown faster than we can secure it and very much became the default. Your network and endpoints still matter, but identity has become the primary security perimeter — the only control point that touches every application your employees use.

Identity should be simpler

You can't simply apply SSO, SCIM, and MFA everywhere because not every vendor supports these standards equally, or at all. We live in a world of bandaids — that's why we have password managers.

Fragmentation makes coverage gaps worse: we end up with multiple ways to solve the same problem, none of them particularly well established. Should authorization be enforced through SSO or SCIM provisioning? There's no central place to manage authentication and authorization, and since they're tightly coupled, you can't treat them as separate problems — yet every vendor implements them differently. This forces every organization to build more identity and security tools, such as proxies to access GitHub or jump hosts to authenticate users via SSH, because the underlying identity systems can't work consistently across all applications. You need tools to discover which services employees signed up for, and more tools to audit which permissions they have in those services.

We're not trying to discourage you from implementing reasonable identity controls: you can, and should, get critical production apps behind SSO and MFA, using a proxy if needed to meet those requirements. This is still the right goal — it's valuable, necessary work that belongs on your IAM roadmap. But you also can't escape the treadmill of slowly forcing every new SaaS application you buy to meet the same requirements. Even organizations with internal requirements to only purchase SaaS apps at the tier that includes SSO (damn that SSO tax!) can't get full compliance.

Access controls are constantly changing, because organizations are constantly changing

Identity is hard to get "right" because it's a moving target that never stops moving.

Not only do access controls need to change often, they need to change quickly. Sure, you should remove unused access (but who does?) and revoke access when employees leave, but it's much more important to ensure employees have access when they need it. No one wants multiple back-and-forths with IT to get the access they need to do their job. This wouldn't be so difficult except that this change is constant: there's always another ticket, another role change, another exception.

Identity is gardening, not engineering. There's constant weeding and replanting. It's highly manual work that doesn't scale the way other security domains do.

Making it scale requires acknowledging what makes it unique. You can't write generic policies that work for every organization because every organization is unique. Not just different tech stacks, but different organizational structures. A startup's flat hierarchy needs different controls than a regulated enterprise with strict separation of duties. People and culture are what make an organization what it is, and this business context must influence how we think about security.

Access decisions require context that security teams don't have

Most organizations want to follow the principle of least privilege: that employees should only have access to what they need. But how do you determine that? We don't know what someone should have access to. IT and security teams lack the business context for these decisions: What is this app? Is it sensitive? What kinds of users should have access to it? This context exists primarily in people's heads, and if documented, it's in an unmaintained spreadsheet. Context decays quickly.

When you don't know what access users need, you make a mess. Users over-request access to unblock themselves. IT copies someone else's permissions hoping it works. These incremental changes accumulate into inconsistent controls that never get cleaned up. You end up with hundreds of unused groups and permissions that made sense three reorganizations ago — and no one knows what's actually needed anymore.

When you get provisioning wrong initially, you spend time cleaning it up later. Debugging why someone's access works or doesn't is nearly impossible. You fear removing access and breaking the business — especially when granting access again requires another ticket and hours of waiting. The industry has invented whole product categories to address this, like IGA for user access reviews required by compliance and ISPM for identifying IAM misconfigurations. But these are symptoms of the underlying problem: that we don't have a systematic way to maintain access controls as organizations evolve.

Building something better

There's no shortage of identity pain points. Even basic controls like SSO and MFA are nearly impossible to implement everywhere. Access requirements constantly change, making them difficult to maintain. And identity decisions require business context that security teams rarely have.

These aren't just theoretical problems. They have real, measurable impact on people's daily work. IT teams spend countless hours on access request tickets that could be automated. Employees get frustrated when they can't access the tools they need to do their jobs. Security teams burn out from the constant manual work of managing exceptions and reviewing access that may or may not be appropriate.

When we founded Oblique, we set out to work on real, tactical, impactful security problems that aren't disappearing anytime soon — and that's what we're doing. Identity is a mess right now, but identity was also a mess before, and it'll probably keep being a mess.

We're tackling authorization for corporate environments first. It's not trendy, but we know it's impactful, because it's what we heard security leaders complain about most. Your IT and security teams want their access controls to be more maintainable. We're here to help you get there.