Delegate authority to those with context

Early in my career, I thought the hard problems in security were the technical ones. Figure out the right architecture, pick a modern cipher suite, write it all in a memory-safe language — that's the important stuff, right? I grew up. People and process problems are always the hardest to solve, especially at scale. And access management is a perfect example of this.

IT and security teams don't want to be gatekeepers — they want to enable the business to move quickly. But if every access change, every application exception, every device approval needs to go through them... then they are gatekeepers. As it relates to access, the problem is that IT often lacks the context to make the right decisions quickly: who is Bob and whose app is it anyway? Meanwhile, business teams have the context but are stuck filing tickets. The solution isn't more people reviewing tickets — it's giving the right people the ability to make access decisions directly.

We've already started delegating security

Engineering figured this out years ago: we have CODEOWNERS for repositories, on-call rotations for specific services, and now developer portals to help consolidate all of that information in one place. Security has learned this lesson too: when we find a security issue, we need to know who’s responsible for it, so that we can ask them to fix it. Security teams face the same ownership question everywhere: which team owns this vulnerable dependency? This unpatched server? This open firewall rule?

We've had the most success with code. Finding bugs centrally and assigning them to dev teams was a disaster, so we "shifted left" and made engineering teams own their vulnerabilities. It's not perfect, but it works better: developers know their code and can prioritize and fix the vulnerabilities they find. We’ve already been delegating the work of fixing security issues, but we’re just starting to give these teams the control over what they prioritize.

Corporate security is also heading in this direction. A few years ago, Kolide innovated in endpoint management by delegating responsibility to end users to install security updates or turn on disk encryption. Instead of IT managing MDM exceptions through tickets, users got direct notifications about security issues on their devices, and were often able to resolve them themselves, without ever opening a ticket. This kind of delegation is possible because it's clear who owns issues for a given laptop: the person signed into it.

More and more tools are embracing this model: Workshop lets teams collectively attest that specific binaries should be allowlisted on their devices, rather than waiting for centralized approval. The team that actually needs Android development tools is better positioned to justify that need than someone in IT who's never built an Android app.

The logical next step is applying this same principle to access management — and some organizations already are.

Distributed access control isn't new

The reality is that access management is already distributed, whether you know it or not. Most SaaS apps are already managed in a decentralized way. The marketing team set up the CMS, so someone on the marketing team (you're not sure who) controls access and invites new colleagues. Some SaaS tools like Slack and Figma let you join automatically if you're part of the same domain, to make it easier for teams to work together (and to grow that per-seat revenue). This happens in smaller organizations before you centralize control with an SSO provider, but even then, there's always shadow IT or apps that don't support SSO.

Delegating authority in access management isn't a new idea. This is just discretionary access control: every resource has an owner, and that owner decides who gets access. It's exactly how sharing a Google doc works.

When we started building Oblique, we found that many tech-forward organizations had already built internal access management systems around this principle. Every single one had ownership baked in — they needed to know who was responsible for each app, service, resource, or group so that they knew who to bother when someone needed access or when compliance required an access review.

App or service owners handle the actual access decisions, including inviting, approving, or reviewing access for what they "own." They've been delegated both the responsibility and the decision-making authority to decide who actually needs access. This isn’t a title, but a responsibility. And this isn't about hierarchy, but about proximity to the resource. A senior engineer who built the service is a better choice than a VP who's never used it. Importantly, you need multiple owners — if your single owner goes on parental leave or quits, you're back to having IT make decisions about things they've never touched. Not only does IT lack context on what this resource is, they have even less context than usual since they haven't been involved in the recent access decisions.

Delegation is how security teams scale

Successful delegation means giving teams authority, not just responsibility. Let the head of Sales decide who gets CRM access: they understand what closes deals, know the cost of additional seats, and have both the business context and financial incentive to make good decisions.

Delegating isn’t easy. It’s scary: what if something goes wrong? But just like a new manager learns to give away more and more control — in a safe environment — security teams are learning to give away more and more responsibility. This shouldn’t be done blindly, but with guardrails to prevent disasters, and accepting that there will be exceptions.

Acknowledging that security can't do everything is part of growing up as an organization scales. Just like in application security or other parts of corporate security, successful delegation in access management means identifying owners, defining their responsibilities — and most importantly, giving them the authority to make decisions that work for them.