Stop Auditing Access Control: Rebuild It for Zero Trust

If your compliance audit is still a checkbox exercise—tick off the RBAC policy, sign off on the MFA report, and call it a day—you're doing it wrong. The old way of auditing access control assumes a trusted network perimeter and static roles. That's dead. NIST SP 800-207 says zero trust grants no implicit trust based on location, and OMB M-22-09 pushed federal agencies toward phishing-resistant MFA by fiscal year 2024. If you're not already there, your audit is a fiction. This is for you if you're an IT or security lead who wants an audit that actually protects your organization, not just a report that impresses a reviewer.

1. Start with the identity truth, not the policy stack

Everyone loves to audit the policy doc. But access control is a sequence: identification, authentication, authorization (Tenable). If you don't know who's in your system, nothing else matters. So your first audit step is to inventory every identity that can touch a resource—human or machine. For each one, verify you can prove who they are. That means checking your authentication methods against NIST's Authenticator Assurance Levels. For most systems handling personal, financial, or operational data, NIST SP 800-63B recommends AAL2: multi-factor authentication with two different factors. If you're still letting people in with just a password, you're failing the most basic test. And don't just check that MFA exists—check that it's phishing-resistant. CISA calls phishing-resistant MFA the 'gold standard' and names FIDO/WebAuthn or PKI-based methods like PIV/CAC as the only real options (CISA Phishing-Resistant MFA). If you see SMS or OTP apps, flag it. That's not just a gap; it's a breach waiting to happen.

2. Map every authorization path, not just the roles

Once you know who's there, you need to know what they can do. Most audit checklists look at RBAC and call it done. But modern access control is a mix. You've probably got RBAC for baseline roles, ABAC for context-aware decisions, and maybe MAC for classified data (Cisco Duo). Your audit must map all of them. Start with RBAC: are roles defined per the ANSI INCITS 359 standard? That means core RBAC (user-role and permission-role assignments) is mandatory, and you should check for static and dynamic separation of duty (NIST RBAC). Then look at ABAC: NIST SP 800-162 defines it as evaluating attributes of subject, object, action, and environment. Are your policies actually using those attributes? For example, do you allow access only during business hours or from managed devices? If not, you're missing the point of zero trust, which says access should be granted per-session based on dynamic policy (NIST SP 800-207). And don't forget the old-school models: DAC gives resource owners control, which is flexible but risky; MAC is centralized and restrictive (Cisco Duo). Audit which model you're using, and be honest about the gaps.

3. Test your MFA, don't just check the box

An audit that verifies MFA is enabled but never tests it is useless. You need to simulate an attack. CISA warns that not all MFA is equal—some are vulnerable to phishing, push bombing, SS7 exploits, and SIM swap (CISA Phishing-Resistant MFA). So during your audit, try to phish your own users. Send a realistic email with a link to a fake login page. If anyone enters their credentials, you've found a training gap and a technical gap. Then check if your MFA is truly phishing-resistant. For example, passkeys are phishing-resistant because they're bound to the specific domain—a passkey for your app won't work on a look-alike site (Microsoft Passkeys). That's the kind of thing you want to see. If you're still using OTPs, you're behind. NIST SP 800-63B also requires that passwords be checked against lists of compromised passwords and that rate-limiting be implemented (NIST SP 800-63B). Audit those settings. Do you reject 'Password1'? Do you lock out after five tries? If not, fix it.

4. Audit the privileged access, the keys to the kingdom

Privileged accounts are the crown jewels. NIST PAM guidance calls them the 'keys to the kingdom' because their compromise plays a role in many major breaches (NIST PAM). So your audit must go deep on these. Check for common PAM controls: credential vaulting with rotation, just-in-time access, session recording, and MFA for privileged sessions (NIST PAM). If you're not using JIT, you're leaving standing privileges that attackers can exploit. For example, with Microsoft Entra PIM, you can require time-based and approval-based role activation (Microsoft PIM). That's exactly the kind of control you want. Also, review your AWS IAM setup if you're in the cloud. AWS IAM defaults to deny, and any explicit Deny overrides an Allow (AWS IAM). That's a good model to audit. Do you have any policies that grant broad wildcard permissions? Those are red flags. Least privilege is the principle: grant only the minimum access needed (Tenable). Audit every policy and ask, 'Does this user really need this?' If you can't justify it, cut it.

5. Verify your SSO and federation, because they're the new perimeter

With zero trust, the perimeter is identity, not the network. That means your single sign-on (SSO) and federation are critical. CISA recommends SSO because it reduces password fatigue and reuse (CISA SSO). But SSO is only as good as the identity provider. Audit your SSO implementation: are you using modern protocols like OpenID Connect or SAML 2.0? OIDC is built on OAuth 2.0 and adds a signed ID token (OpenID Connect). SAML uses XML assertions (SAML 2.0). Both are fine, but make sure you understand the difference. OAuth 2.0 is an authorization framework, not authentication—an access token doesn't prove identity (RFC 6749). That's a common mistake. Also, check for PKCE if you're using OAuth for public clients. RFC 7636 says PKCE mitigates code interception (RFC 7636). And beware of bearer tokens: anyone who holds one can use it (RFC 6750). So your audit should ensure tokens are short-lived and scoped. For AWS, if you're using federation, you should be using IAM roles with temporary credentials, not long-term keys (AWS IAM Roles). That's a huge win for security.

6. Automate the audit with continuous monitoring

An audit that happens once a year is already stale. Zero trust requires continuous verification. NIST SP 800-207 says access decisions are per-session and based on dynamic policy (NIST SP 800-207). So your audit should be a continuous process, not an event. Use tools that give you visibility. For example, Microsoft Entra Conditional Access is a policy engine that uses identity-driven signals to make decisions (Microsoft Conditional Access). You can set policies that require MFA or block access based on risk. Audit those policies regularly. Also, use SCIM for automated provisioning. RFC 7643 defines SCIM for managing identity data, including Users and Groups (RFC 7643). If you're manually provisioning and deprovisioning, you're going to have stale accounts. Automate it. And for privileged access, use PIM with access reviews to ensure users still need their roles (Microsoft PIM). That's your ongoing audit.

A comparison of access control models for your audit

What I'd actually do

Stop auditing the old way. Start by implementing phishing-resistant MFA everywhere, using passkeys or FIDO2. Then, map your access and cut everything that isn't least privilege. For privileged accounts, deploy a PAM solution with JIT access. And make your audit continuous with Conditional Access and automated provisioning. You'll not only pass your audit, you'll actually be secure. That's the only audit that matters.

Sources

• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• CISA Phishing-Resistant MFA - https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• RFC 7636 (PKCE) - https://www.rfc-editor.org/rfc/rfc7636
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control