In August 2026, more than 150 organizations — Anthropic, Microsoft, Google, AWS, Cisco, banks, governments, and cybersecurity firms from around the world, including our own team at Faraday — signed an open letter led by OpenAI asks every organization for something that sounds simple but, in practice, is where most security projects die:
“Upgrade or replace systems to build in least privilege, strong access controls, and defense in depth.”
The problem isn’t understanding the concept. It’s that implementing it badly breaks workflows, generates pushback from product teams, and ends in a quiet rollback six months later. This guide is about how to do it without that happening.
The most common mistake: least privilege as a “big bang” project
Trying to migrate the entire organization to minimal permissions in a single push almost always fails. It generates broken tickets, poorly documented emergency access, and a security team that ends up reverting changes under pressure. The approach that works is incremental and based on real usage data, not on what each role “should” need in theory.
Step 1 — Measure before you restrict
Before removing anyone’s permissions, instrument what’s actually being used:
- Access logs for APIs, databases, and file systems over at least 30 days.
- Access analysis tools (AWS Access Analyzer, GCP Policy Analyzer, or equivalents on-prem) to detect permissions granted but never exercised.
- Identify “inherited” access from previous roles the person no longer holds.
Rule of thumb: if a permission hasn’t been used in 90 days, it’s a candidate for removal — not for an alert, for direct removal, with a fast-track request process if it’s needed later.
Step 2 — Migrate in layers, not by whole system
Instead of “let’s apply least privilege to the entire payments system,” split by access type:
- Read access — almost always safe to restrict first, with low risk of breaking production flows.
- Write/modify access — needs a test window with easy rollback.
- Administrative/deletion access — the most sensitive; migrate last and require explicit approval per change.
This gives you quick wins (most of the risk is usually concentrated in the 10-20% of write/admin access) without blocking day-to-day operations from day one.
Step 3 — Defense in depth: layers that actually reinforce each other
Poorly implemented defense in depth is just “stack a few firewalls.” Done well, each layer covers the failure of the previous one:
| Layer | What it covers | Concrete example |
|---|---|---|
| Network | Segmentation, zero trust networking | Microsegmentation between internal services, not just perimeter |
| Identity | Strong authentication, continuous verification | MFA + step-up authentication on sensitive actions |
| Application | Input validation, session control | Rate limiting, WAF with business-specific rules (not just generic ones) |
| Data | Encryption, tokenization, DLP | Encryption at rest AND in transit, with audited key rotation |
| Monitoring | Anomaly detection | Alerts on permission usage outside the normal pattern |
The key: each layer must assume the previous one has already failed. If your WAF is your only application-layer defense, you don’t have defense in depth — you have a single point of failure with a fancy name.
Step 4 — Legacy systems: the special case
The letter explicitly acknowledges systems that “cannot be patched without disrupting essential services” — hospitals, power infrastructure, industrial systems. For these cases, apply:
- Aggressive segmentation: isolate the legacy system on its own network, with no direct access from the internet or from modern systems without an intermediary proxy.
- Compensating controls instead of modifying the system itself (see the dedicated post on this topic).
- Reinforced monitoring specifically in that segment, since you can’t rely on the system defending itself.
Step 5 — Communicate the change as an improvement, not friction
Resistance to least privilege almost always comes from teams afraid of getting locked out at a critical moment. Mitigate it with:
- A documented “emergency access” process approved within minutes (not days), audited afterward.
- Dashboards showing what was restricted and why, visible to affected teams.
- Involving product leads in prioritizing what gets migrated first.
Implementation checklist
- ☐ Instrument real usage logs for permissions (minimum 30 days)
- ☐ Identify permissions unused for 90+ days
- ☐ Migrate read access first, admin access last
- ☐ Map the 5 defense-in-depth layers and identify which are missing
- ☐ Isolate unpatchable legacy systems into their own segments
- ☐ Define an audited emergency access process
- ☐ Measure team velocity impact before/after the change
Part of a series on how to put into practice the principles from OpenAI’s open letter on collective cyber defense (August 2026). Back to the full guide.
