A departing employee’s directory account is disabled, but an application session remains active. An administrator uses strong authentication, but account recovery still relies on a weaker method. A service account has production access, but nobody knows who owns it.
These scenarios expose a common problem: identity controls can look complete on a project plan while leaving important access paths unprotected. Buying an identity platform, enabling multifactor authentication, and conducting annual access reviews are useful steps. None proves that access is appropriate—or that it ends when it should.
For business leaders, IT managers, and security teams, the objective is straightforward: give people and systems the access they need, under appropriate conditions, and verify that everything else is denied.
Identity Management Is an Operating Discipline
Identity and access management, or IAM, extends beyond the sign-in screen. It includes account creation, authorization, privileged access, application sessions, machine credentials, recovery, and removal. NSA and CISA’s IAM guidance reflects this broader scope, addressing governance, environmental hardening, federation, multifactor authentication, and auditing.
Implementation therefore needs continuing ownership. Business leaders define acceptable access; application owners explain what permissions enable; IT and security teams implement and test the controls. Exceptions need accountable owners and expiration dates.
Do not measure identity security only by the controls you have enabled. Measure whether those controls allow the right actions, deny the wrong ones, and remove access when required.
Seven Common Implementation Mistakes
1. Treating All Multifactor Authentication as Equally Protective
The mistake: Declaring MFA complete without examining every authentication method users can actually use. A strong preferred method provides less assurance when a weaker fallback remains available.
NIST’s authentication guidance does not classify manually entered one-time codes or out-of-band authentication as phishing-resistant. WebAuthn/FIDO2 can provide phishing resistance by binding authentication to the legitimate service’s domain.
Corrective action: Prioritize phishing-resistant authentication for administrators and sensitive applications. Inventory enrollment, recovery, fallback, and help-desk reset procedures—not just the normal sign-in experience. MFA remains valuable, but different methods address different risks.
Test it: Use an approved test account to exercise every permitted route. For example, determine whether an administrator enrolled with a security key can still authenticate through a weaker recovery method. Compare each route with the organization’s intended assurance level.
2. Granting Broad Permissions and Never Narrowing Them
The mistake: Giving a deployment team broad access to get a system running, then leaving those permissions in production. “Temporary” access becomes permanent when nobody owns its removal.
AWS IAM guidance recommends granting only the permissions required for a task. It also cautions that AWS managed policies may not provide least privilege for an organization’s particular use case.
Corrective action: Define access by business task, resource, and relevant conditions. A reporting workload may need to read a specific dataset; that does not justify permission to modify unrelated storage or administer identities. Record an owner, justification, and expiration for exceptions.
Test it: Validate both allowed and prohibited actions. Confirm that the reporting workload can retrieve approved data and cannot change access policies. A successful business transaction proves functionality—not least privilege.
3. Treating Offboarding as an Account-Disable Operation
The mistake: Assuming that disabling a central directory account immediately terminates every application session.
Microsoft’s Entra ID documentation explains that application-issued session tokens are controlled by the application; Entra ID cannot directly revoke them. Actual access removal can depend on application behavior, token expiration, and deprovisioning.
Corrective action: Build an offboarding checklist covering directory access, application accounts, refresh tokens, application sessions, and manual deprovisioning exceptions. Identify applications that require separate administrative action and assign responsibility for completing it.
Test it: Conduct a controlled departure exercise using a test identity with active sessions in critical applications. Measure when access actually stops in each application. Record unresolved sessions as control gaps rather than marking offboarding complete when the directory account is disabled.
4. Overlooking Service Accounts and Workload Identities
The mistake: Applying strong lifecycle controls to employees while applications, scripts, and integrations continue using persistent credentials with unclear ownership.
AWS recommends temporary credentials through IAM roles for workloads wherever possible, while recognizing that some situations still require long-term credentials. The practical goal is to reduce persistent secrets without breaking necessary operations.
Corrective action: Inventory workload identities and document each identity’s owner, purpose, permissions, credential lifetime, and dependencies. Replace persistent keys with temporary credentials where supported. Document unavoidable exceptions and establish secure storage, replacement, and revocation procedures.
Test it: Sample production workloads and ask their owners to demonstrate how credentials are issued and revoked. Use an approved test to confirm that an obsolete credential stops working without unnecessarily disrupting the service. A documented procedure is not enough if nobody has verified it.
5. Using Outdated Password Rules as the Main Defense
The mistake: Treating mandatory character combinations and scheduled password changes as the foundation of account security.
NIST SP 800-63B-4, finalized July 31, 2025, prohibits composition rules and routine periodic password changes within its requirements. It requires at least 15 characters for single-factor passwords; passwords used within MFA may have an eight-character minimum. It also requires screening against commonly used, expected, or compromised passwords and permitting password managers.
Corrective action: Align password policy with applicable assurance and compliance requirements. NIST guidelines are not a universal legal mandate for every business. Preserve password changes when compromise is suspected or established, and do not mistake better password policy for a substitute for MFA.
Test it: Check actual behavior: can users paste password-manager-generated passwords? Are known compromised passwords rejected? Do connected applications enforce the intended policy, or maintain separate, weaker rules?
6. Reviewing Assigned Roles but Ignoring Effective Access
The mistake: Approving a user’s visible role without examining everything that contributes to their actual access.
In AWS, for example, access reviews must account for relevant resource policies and cross-account access—not just identity policies. AWS recommends using IAM Access Analyzer to review public and cross-account access, validate policies, and help identify unused access.
Corrective action: Review effective capabilities across group memberships, role assignments, resource policies, external sharing, and delegated administration. Ask application owners to approve understandable actions and resources, rather than unfamiliar group names.
Test it: Replace “Does this person need the Finance-Shared group?” with “Should this person download payroll exports or change payment instructions?” Then verify those capabilities using approved testing and relevant policy-analysis tools. Business-readable questions produce more meaningful decisions than lists of technical labels.
7. Strengthening Controls Without Planning for Lockout
The mistake: Enforcing restrictive access policies without a tested way to recover administrative control when normal authentication fails.
For Entra ID specifically, Microsoft recommends at least two emergency access accounts, phishing-resistant authentication, monitoring their use, and functionality checks at least every 90 days. These are product-specific recommendations, not universal requirements for every platform.
Corrective action: Document emergency-access authorization, secure credential custody, recovery steps, and post-use review. Design the recovery path to avoid the dependencies whose failure could lock out normal administrators. Do not turn emergency access into an unmonitored shortcut.
Test it: Conduct an approved recovery drill. Confirm that emergency authentication works, necessary administrative tasks are possible, and sign-ins generate alerts that reach responsible personnel.
A Management Checklist That Measures Results
Use the following as proposed management measures, not industry benchmarks. Set targets according to business risk and track exceptions alongside progress:
- Authentication: Coverage of phishing-resistant authentication for privileged users, including fallback and recovery paths.
- Offboarding: Time from departure notification to verified application-access removal.
- Workload ownership: Number of workload identities without an accountable owner.
- Exceptions: Number of overdue access exceptions and their business impact.
- Revocation testing: Percentage of critical applications included in access-removal exercises.
- Recovery readiness: Date, outcome, and unresolved findings from the last emergency-access drill.
Review these measures with the people authorized to resolve gaps. A dashboard without assigned actions is reporting, not governance.
Make Verification Part of Implementation
Effective identity security requires more than enabling features. It requires evidence that permissions match business needs, weaker access paths are addressed, departures end access, and recovery works under pressure.
Start with one privileged role and one critical application. Trace authentication, authorization, recovery, and revocation from beginning to end. Test the boundaries, document failures, and assign corrective actions. Then expand that discipline across the environment. That is how IAM becomes a reliable operating capability rather than a completed software project.