When a federal audit reveals that 76,000 employees all had access to privileged accounts, it's not a technology failure. It's a result of outdated assumptions about access control.
The Department of Homeland Security Office of Inspector General found that U.S. Customs and Border Protection couldn't inventory its privileged accounts, monitor them, or reliably remove access when people left or changed roles. The result: investigators mapped more than 100 attack paths through the environment.
These failures didn't stem from missing technology. They came from persistent myths about access control that compliance managers still encounter in SOC 2 Type II readiness assessments and ISO/IEC 27001 surveillance audits. Let's dismantle them.
Myth 1: "If We Control Human Accounts, We've Covered Access Control"
Reality: Service accounts are where your exposure actually lives, and they're almost never monitored with the same rigor as user accounts.
Service accounts run automated processes, execute scheduled tasks, and connect applications to databases. They hold elevated privileges by design. And because no human logs in with them daily, security teams treat them as infrastructure rather than identity.
The CBP audit found that the entire workforce could operate service accounts with elevated privileges. That's not a service account problem. That's a permissions inheritance problem that nobody was watching.
ISO/IEC 27001 Annex A control 5.15 (Access Control) and A.5.16 (Identity Management) don't distinguish between human and non-human identities when they require you to manage the full user lifecycle. Your service account inventory belongs in the same access review cycle as your user accounts. If you're running quarterly access reviews for employees but annual reviews for service accounts, you've created a gap an auditor will flag.
For SOC 2, CC6.2 (Logical and Physical Access Controls) requires you to identify and authenticate users. Service accounts are users. If you can't produce an inventory of service accounts with current privilege levels and business justifications, you're not meeting the criteria.
Myth 2: "We'll Know When Someone Still Has Access After They Leave"
Reality: You won't know unless you're testing for it, and most organizations don't test for it until an auditor asks.
The CBP audit found the agency "did not reliably strip access from its network when personnel left the agency or moved to a different role." This is the single most common finding in access control assessments, and it persists because organizations assume their offboarding workflow actually works.
Your HR system triggers a ticket. IT closes the ticket. But did the Active Directory group membership get removed? Did the application-level entitlements get revoked? Did the VPN certificate get invalidated? Unless you're sampling terminated accounts and attempting to authenticate with them, you're trusting a process you haven't verified.
ISO/IEC 27001 Annex A control 5.18 (Access Rights) requires you to review and adjust access rights when employment changes or ends. That's not a one-time configuration. That's a control you need to test. Pull a list of terminations from the last 90 days, attempt authentication, and document the results. If even one former employee can still log in, you've got a major nonconformity waiting to happen.
For SOC 2 CC6.1 (Logical and Physical Access Controls), you need evidence that your process works in operation, not just in theory. Auditors will ask for your termination list and your access removal tickets. If the dates don't align within 24 hours, they'll ask why.
Myth 3: "We Can Inventory Privileged Accounts When We Need To"
Reality: If you can't inventory them right now, you can't monitor them, and you definitely can't respond when something goes wrong.
The CBP report noted the agency "could not always tell which of its accounts carried elevated privileges in the first place." This isn't an edge case. It's what happens when privileged access grows organically over years without a central registry.
Consider a team that grants Domain Admin rights for a server migration, then forgets to revoke them. Or a developer who gets temporary database owner permissions that become permanent because nobody tracked the expiration. Multiply that across 100 major applications and 4,500 facilities, and you've lost the ability to answer the most basic question an auditor will ask: "Who has privileged access to what?"
Your privileged account inventory needs to be a living document that includes account name, privilege level, business justification, owner, and last review date. If you're building that inventory in response to an audit request, you're already behind.
ISO/IEC 27001 Annex A control 8.2 (Privileged Access Rights) explicitly requires you to control and review the allocation and use of privileged access rights. You can't review what you can't enumerate.
Myth 4: "Access Reviews Are a Compliance Checkbox"
Reality: Access reviews are your early warning system for privilege creep, and they only work if you're asking the right questions.
Most access review processes send a spreadsheet to a manager and ask, "Does this person still need access?" The manager clicks "approve" on everyone who still works for them, and the compliance team files the evidence.
That's not an access review. That's documentation theater.
The CBP audit found that access wasn't properly managed when personnel moved to different roles inside the agency. That's because access reviews rarely ask, "Does this person need this level of access for their current role?" They just ask, "Does this person still work here?"
Your access review process should include:
- Current role and responsibilities for each account holder
- Specific systems and privilege levels being reviewed
- Business justification for elevated access
- Attestation that access aligns with current job function
- Automatic flagging of access that hasn't been used in 90 days
For SOC 2 CC6.2, you need evidence that access reviews are actually identifying and remediating inappropriate access. If your review process has never resulted in access being revoked, your auditor will question whether it's operating effectively.
Myth 5: "We'll Fix Access Control Issues When We Have More Resources"
Reality: Access control failures are almost never resource problems. They're process and accountability problems.
CBP told investigators the lapses traced to "human error and to an inability to track how account access changed over time." That's the same explanation U.S. Citizenship and Immigration Services gave in a 2022 audit that found identical failures.
You don't need more staff to maintain a service account inventory. You need a requirement that every service account be documented before it's created. You don't need a bigger budget to remove access when people leave. You need your offboarding process to include verification that access was actually removed.
The organizations that succeed at access control treat it as an operational discipline, not a compliance project. They assign ownership. They build verification into existing workflows. They test their controls before auditors do.
What to Do Instead
Start with visibility. Build an inventory of privileged accounts today. Include service accounts, admin accounts, and any account with write access to production systems. Assign an owner to each one.
Then build verification into your existing processes. When someone leaves, don't just close the ticket. Test that authentication fails. When you grant temporary elevated access, set a calendar reminder to verify it was revoked.
For your next access review, don't just ask managers to approve their team's access. Ask them to justify why each person needs the specific privileges they hold. Flag any access that hasn't been used in 90 days and require reauthorization.
Finally, recognize that access control isn't a technology you implement once. It's a discipline you practice continuously. The organizations that treat it that way don't end up in audit reports with more than 100 attack paths through their environment.
