A departing employee’s directory account is disabled. The ticket is closed. Yet a separately managed application account remains active, and an existing session still works. The offboarding process looks complete—until someone tests it.
This scenario illustrates a fundamental challenge in identity and access management: a configured control is not necessarily an effective control. Multifactor authentication helps protect sign-ins, but it does not resolve excessive permissions, orphaned service accounts, incomplete departures, or weak recovery procedures.
For business leaders, IT managers, and security teams, the objective is straightforward: know who and what can access your systems, limit that access to legitimate needs, remove it when circumstances change, and verify the outcome. The work is continuous, not a one-time implementation.
Make Access Control an Operating Process
The joint CISA–NSA identity and access management guidance brings together identity governance, authentication, and monitoring. Your operating process should connect those disciplines rather than treating them as separate projects.
For every checklist item below, record four things:
- Owner: The person accountable for the control, including coordination with application and business owners.
- Status: Implemented, partially implemented, missing, or covered by an approved exception.
- Evidence: A report, configuration, approval record, or test result demonstrating what actually happens.
- Next review date: When the control will be reassessed, with earlier reviews triggered by material changes.
The evidence suggestions are practical implementation aids, not regulatory requirements. A smaller organization can start with a controlled register; a larger organization may automate collection and review. Neither approach removes the need for accountability.
The Practical Identity and Access Checklist
☐ 1. Inventory Identities and Permissions
Include employees, contractors, guests, administrators, local accounts, service accounts, and application identities. Reconcile directory records with critical applications: the central directory will not necessarily reveal every account or sign-in path.
Record each identity’s owner, purpose, permissions, and relevant lifecycle information. Flag accounts with no clear business need or accountable owner. For example, an active contractor account should prompt a check against the current engagement—not an assumption that access remains appropriate.
Evidence: An account-and-permission register reconciled against directories and critical applications, with unresolved discrepancies assigned for investigation.
☐ 2. Formalize Onboarding, Role Changes, and Departures
Require approved access requests tied to job responsibilities. When someone changes roles, review and remove obsolete permissions rather than simply adding new ones. Otherwise, an internal transfer becomes a mechanism for accumulating access.
Connect departure notifications to directory disablement, application deprovisioning, and session revocation where supported. Identify who initiates the process, who executes it, and who verifies completion. Include contractors and guests whose departure may not appear in the employee workflow.
Evidence: Joiner, mover, and leaver records showing approvals, changes, removal actions, and completion verification.
☐ 3. Limit Administrative Access
Grant only the permissions needed for the task. Separate everyday accounts from administrative accounts so routine email and browsing do not occur under elevated privileges. Where supported, use approved, time-limited privilege elevation instead of permanent administrative access.
For example, an administrator troubleshooting one application should not automatically need unrestricted control of the identity platform. Microsoft’s identity governance guidance recommends separate administrative accounts, least-privileged roles, and just-in-time access.
Evidence: A privileged-account inventory, approved role assignments, and records of privilege elevation and review.
☐ 4. Enforce MFA and Prioritize Phishing Resistance
Check coverage across email, remote access, file storage, and administrative systems. Enrollment alone is insufficient: confirm that policy actually requires MFA and identify bypasses, legacy authentication, and excluded accounts.
Prefer appropriately configured FIDO/WebAuthn authenticators for phishing-resistant authentication. As CISA explains, MFA methods offer different levels of protection. Number matching improves push-based authentication but is not equivalent to phishing resistance. Document unsupported systems and their migration or compensating-control plans.
Evidence: A coverage report and controlled tests demonstrating that sign-ins cannot bypass the required authentication policy.
☐ 5. Replace Outdated Password Rules
For systems implementing NIST SP 800-63B-4, passwords used as the sole authentication factor must contain at least 15 characters. Passwords used within MFA may be shorter but must contain at least eight characters. These requirements apply within the guideline’s scope; they are not a universal legal mandate.
Block common or compromised passwords, support password managers, and avoid arbitrary periodic changes and character-composition rules. Require a change when compromise is evident. Test application behavior rather than relying solely on the written policy.
Evidence: Documented requirements and verified settings, including password-length enforcement and blocked-password checks.
☐ 6. Govern Nonhuman Identities
Service accounts and application identities need owners, defined purposes, and limited permissions. Include integrations, automation jobs, and AI applications that can retrieve data or perform actions. An application identity with broad document access can expose information even when every employee uses MFA.
In Azure, prefer managed identities for supported workloads rather than manually managed service credentials. Where credentials remain necessary, protect them and define their replacement and revocation procedures. Investigate dependencies before removing an apparently unused identity.
Evidence: A workload-identity register with owners, permissions, credential-management arrangements, and review decisions.
☐ 7. Centralize Authentication Where Practical
Assess which applications can use single sign-on. Central authentication can simplify policy enforcement and lifecycle management, but an application is not fully governed merely because its main login page supports SSO.
Inventory local accounts, alternate login paths, and exceptions. For example, a local administrator account may bypass the protections applied to federated users. Determine whether those paths can be disabled or require separate controls and monitoring.
Evidence: An application integration map and an exception register identifying owners, risks, protections, and review dates.
☐ 8. Review Access and Act on Findings
Ask resource owners to confirm whether access remains necessary. Include application permissions, guest access, sensitive groups, and privileged roles. Provide enough context for meaningful decisions: a list of unfamiliar account names encourages rubber-stamping.
Track removal through completion. If a manager rejects a former team member’s access to financial reports, the review is not finished until that permission is removed and verified. Set review frequency according to sensitivity, privilege, and organizational change.
Evidence: Recorded decisions, assigned remediation actions, and proof that rejected access was removed.
☐ 9. Monitor Identity Activity
Collect relevant authentication and administrative logs. Investigate unexpected privileged activity, account creation, permission changes, and changes to authentication or recovery settings. Establish expected behavior so unusual but authorized maintenance can be distinguished from suspicious activity.
Every alert needs a destination and a response process. Define who assesses legitimacy, how they obtain business context, and when they escalate. Logging without someone responsible for acting on it leaves a substantial operational gap.
Evidence: A controlled alert test showing delivery to a named responder and a documented assessment.
☐ 10. Test Revocation, Recovery, and Emergency Access
Verify that departure and compromise procedures stop access to critical applications. Disabling an identity does not necessarily terminate every application session immediately; Microsoft documents token and application-session limitations. Test application behavior and use additional revocation measures where needed.
Document recovery procedures with appropriate identity verification and notifications. Secure emergency-access arrangements, monitor their use, and test them without creating an uncontrolled bypass. Recovery should restore legitimate access—not offer attackers an easier route around authentication.
Evidence: A controlled revocation test and recovery exercise, including identified limitations and corrective actions.
Measure Results, Not Just Configuration
Use a small set of operational measures to expose gaps and guide investment:
- MFA coverage: Distinguish enrollment from enforced protection and report exceptions separately.
- Accounts without owners: Track unresolved human and nonhuman identities.
- Unnecessary access awaiting removal: Measure outstanding remediation, not just completed reviews.
- Verified departure removal time: Measure from notification to confirmed removal across relevant systems.
These are proposed management measures, not industry benchmarks. Define their scope and denominators clearly. A strong percentage can conceal a serious weakness if privileged accounts or critical applications are excluded.
Close the Loop on Access
A control is not complete because it is enabled—it is complete when someone owns it, its coverage is known, and a test demonstrates that it works.
Start with your critical applications and highest-risk identities. Assign owners, document gaps, prioritize corrective work, and schedule controlled tests. Bring business owners into decisions about legitimate access rather than leaving every judgment to IT.
The next step is practical: select one critical application, trace an identity from approved access through removal, and verify the result. Use what that test reveals to strengthen the process across your organization.