Skip to main content
Everyone Needs Privileged Access (No, They Don't)Access & Identity Management
5 min readFor Information Security Officers

Everyone Needs Privileged Access (No, They Don't)

The Conventional Wisdom

In many large organizations, you'll hear this: "Our environment is too complex to lock down privileged access tightly. We need flexibility. Our teams can't wait three days for an approval workflow when production is down."

This reasoning is common. Service accounts get admin rights because "the application won't work otherwise." Entire departments get elevated privileges because "they might need it someday." Access reviews become rubber-stamp exercises because "these people are trusted employees."

The Department of Homeland Security's Inspector General recently highlighted the dangers of this logic. At U.S. Customs and Border Protection (CBP), every network user, all 76,000 employees, could operate a service account with elevated privileges. Not some users. Not most users. Every user could modify credentials and security settings across an environment running more than 100 major applications across 4,500 facilities.

Why We Disagree

Here's the uncomfortable truth: your environment isn't too complex for proper access controls. You've made it too complex by avoiding the hard work of defining who actually needs what.

The "we need flexibility" argument confuses speed with preparedness. You don't need everyone to have privileged access for emergencies. You need documented break-glass procedures, properly scoped emergency accounts, and change management that distinguishes between "production is down" and "I don't want to fill out a form."

CBP told investigators their problems traced to "human error" and an inability to track access changes over time. This explanation reveals the real issue: they'd designed a system that depended on humans manually tracking thousands of access decisions instead of building controls that prevented the wrong decisions in the first place.

When you can't inventory which accounts have elevated privileges, another finding from the audit, you're not dealing with complexity. You're dealing with neglect. ISO/IEC 27001 Annex A Control 5.18 (access rights) and SOC 2 CC6.2 (logical and physical access controls) don't include exemptions for "our environment is complicated." They require you to know who has access to what and why.

The Evidence

The Inspector General's team mapped more than 100 attack paths through CBP's environment. An attacker doesn't need to find one misconfigured account or one unpatched system. They have more than 100 documented routes to move laterally, escalate privileges, and reach sensitive data.

This wasn't theoretical. The audit included penetration testing that proved the vulnerabilities were exploitable.

The report also found CBP couldn't reliably revoke access when employees left or changed roles. This is User Lifecycle Management 101, the process that should trigger automatically when HR updates an employee record. If you're relying on manual notifications and hoping someone remembers to disable accounts, you've already failed CC6.1 (logical and physical access controls for system components).

What makes this especially damaging: CBP holds law enforcement records and biometric data used at ports of entry. The Inspector General noted these systems are "high-visibility targets for attackers who aim to disrupt mission-essential operations or steal sensitive information." When your access controls fail at this scale, you're not just risking a compliance finding. You're risking operational disruption and data exposure that affects thousands of travelers and investigations.

The pattern repeats. The same Inspector General found similar failures at U.S. Citizenship and Immigration Services in 2022: inadequate access removal, no verification after transfers, poor service account management. Same root causes four years apart: insufficient internal controls and inadequate oversight.

What to Do Instead

Start with privilege itself. Most organizations define privileged access as "anything an admin can do." That's backwards. Define it as "access that can materially harm the organization if misused." Then work backwards to determine the minimum number of people who need each type of elevated access.

For service accounts specifically:

  • Inventory them first. You can't secure what you can't see. Tools exist (CyberArk, BeyondTrust, Delinea) but you can start with PowerShell scripts and LDAP queries if budget is tight.
  • Assign ownership. Every service account needs a named owner who can explain what it does and why it needs its current permissions.
  • Rotate credentials. If you can't rotate a service account's credentials without breaking something, you don't control that account, it controls you.
  • Monitor usage. Service accounts should have predictable behavior. Alert on deviations.

For user access:

  • Implement automated deprovisioning tied to your HR system. When someone's employment status changes, their access should change that day, not whenever someone remembers to submit a ticket.
  • Conduct access reviews that matter. Don't ask managers to certify 200 access grants in one spreadsheet. Show them the ten highest-risk entitlements their reports hold and make them justify each one.
  • Require re-approval for privileged access every 90 days. If you can't articulate why someone still needs admin rights quarterly, they probably don't.

For monitoring, ISO/IEC 27001 Annex A Control 8.15 (logging) requires you to produce, store, and review logs that track privileged actions. That means:

  • Capturing who accessed what, when, from where
  • Alerting on privilege escalation attempts
  • Reviewing privileged account activity weekly, not quarterly

When the Conventional Wisdom IS Right

Large environments genuinely are complex. If you're running 100+ applications across thousands of locations, you can't manually approve every access request without grinding operations to a halt.

The conventional wisdom gets one thing right: you do need flexibility. But flexibility comes from good architecture, not loose controls. Build your access management system so that:

  • Common requests auto-approve based on role and context
  • Emergency access is available through documented break-glass procedures
  • Temporary elevated access expires automatically
  • Audit trails capture everything

You also can't fix access controls overnight in an environment CBP's size. The Inspector General acknowledged that CBP began revoking excessive privileges and scanning for similar misconfigurations while the audit was still open. That's the right response: start with the highest-risk accounts, work systematically, and prove progress.

If you're in the middle of a major migration, a merger, or a platform consolidation, perfect access controls might not be achievable immediately. That's fine. What's not fine is using complexity as a permanent excuse to avoid the work.

Your auditor will ask whether you've documented your privileged accounts, whether you've reviewed access in the last 90 days, and whether you can demonstrate that terminated employees lose access promptly. If your answer is "our environment is too complex," you're not explaining a control gap. You're describing a major nonconformity.

You Might Also Like