Access approvals considered harmful
Access approvals are a feature in categories of software bearing fancy names like Entitlement Management, Identity Governance, Privileged Access Management (PAM), and Cloud Access Security Brokers (CASB). The idea is to gate risky access behind a multi-party workflow that delegates decisions to managers, oncall personnel, or others who presumably have better context. It’s safer than just granting access, so, it’s a security win, right?
If we’re unsure about access being safe, adding an approval step can just be kicking the can down the road. In a recent conversation with Clint Gibler, I dug into access approvals and where they go wrong. Here, I want to break down some problems and suggest alternatives that improve security while minimizing friction.
Don’t reinforce risky access paths, build a safer control plane
Logging into production environments or assuming elevated cloud roles is inherently risky. An errant keystroke could cause an incident. Adding a quick review doesn’t make it safe. Putting these actions behind approvals means the actions will still happen.
Long term, find ways to make that access unnecessary for regular workflows. Create safer access paths that don’t require gates. Config files can be viewed safely when they’re IaC, system logs can be shipped to observability stacks, and prod changes can be orchestrated through CI/CD.
Don’t make uninformed decisions, require pull requests
Access requests often lack context and the approver can’t know what exact access is needed. If someone requests administrator access in a cloud environment, they might be checking a bill, modifying a production stack — or spinning up crypto instances. Frequent approvals lead to rushed justifications and perfunctory reviews which can make approvals automatic and meaningless. When access is inherently risky, like making live changes to production, draw on software engineering best practices: version control, pull requests, and CI/CD pipelines.
At LaunchDarkly, our Security team built a tool to reduce direct prod access (e.g. SSH, AWS console). We maintain a GitHub repository with templated Go scripts for common tasks. Once reviewed, approved (with full context!), and merged, the code uses GitHub Actions to launch AWS Fargate tasks that perform the sensitive tasks from within our prod environments. This setup streamlines safe access using the same techniques we use to keep deployments secure. It reduces the need for low context approvals.
Don’t introduce approval latency, do support emergency “break glass” access
There are emergency situations where we want to allow unsafe access methods. Requiring someone to submit a pull request to perform forensic surgery on a borked host may not make sense in the midst of a SEV1 incident. “Break glass” means the access should be loud and expensive, with alerts, credential rotation, and clear follow-up actions. This is reserved for high severity situations where no safe alternative exists.
At LaunchDarkly, our break glass process is simple but intentional. The on-call Incident Manager has the authority to approve access, reducing delays when fighting fires. We document this access in runbooks so it’s ready when needed for quick debugging or repair, and it automatically triggers critical security alerts. After an incident, we identify changes that might cut down on similar access needs in the future.
Don’t use approvals to prevent spoofing, ask for identity evidence
If approvals are meant to verify whether a request is legit (“are you really who you say you are?”), they’re confusing authentication with authorization. An attacker with valid credentials can just as easily submit a “legit” request. If the access request system itself can’t tell whether a request is legitimate, how is an approver supposed to? This setup is just as vulnerable to user error as MFA Fatigue attacks, where repeated prompts wear people down and slip-ups happen.
If spoofing is the concern, our focus should be on building resilience to identity-based threats and requiring additional proof from the requester — not a rubber stamp from someone else. That could mean an MFA re-authentication or a device trust check, putting the burden of proof back where it belongs.
Don’t block access, study justifications
When risky access is frequent but there’s no clear, safer option in place, approvals might seem like a quick fix. But when approvals are routine, they can slow teams down and eat away at security’s credibility each time work is left in limbo.
A more iterative approach is to use auditable requests in place of approvals. With this model, users submit access requests with context — like a link to a ticket — and get access without waiting for approval. These justifications give security teams valuable insights into why people need this access, which allows for real-time suggestions of safer alternatives when possible. Over time, this data helps define use cases for safer access methods.
Instead of relying on access approvals, systems should focus on creating pathways with context-appropriate least privilege access. Routine actions should be streamlined, with decision delegation only in exceptional cases. By shifting to more purpose-built processes, we move from “approving access” to people moving fast while reducing security risks.
