IAM Fundamentals for IT Leaders
This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. Requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.
You've just finished a security audit and found yourself staring at a gap report that keeps mentioning IAM without explaining what actually needs to happen in your environment. Or maybe a customer's questionnaire is asking about your "identity and access management framework" and you're not sure whether that's something you have or something you need to build. Either way, identity and access management is foundational to everything else you do in security, and it's worth understanding not just the terminology but how the pieces fit together and why they matter to your specific risk profile.
Identity and access management sounds like a single thing, but it's actually five distinct layers working together. The first is authentication—proving that someone is who they claim to be. The second is authorization—determining what that proven person is allowed to do. The third is governance—keeping access aligned with reality as people change roles and leave the organization. The fourth is access control models—the different ways you can implement authorization at scale. And the fifth is audit and accountability—proving that access decisions were made appropriately and that people did what they claimed they did. Most organizations have pieces of each layer in place, but the real security is in how those pieces connect.
Authentication: The Identity Proof Layer
Authentication sits at the entry point to everything else. Before anyone can access anything, the system needs to verify that they're actually who they claim to be. This is where it starts, and getting it wrong means everything downstream is compromised.
Passwords have been the standard for decades, but they're also the weak link that most attacks exploit. People reuse passwords across systems, write them down, fall for phishing, and choose ones that are easy to remember and therefore easy to crack. From a compliance perspective, passwords alone fail—auditors and insurance requirements increasingly reject password-only authentication as insufficient. From a practical security perspective, every major breach you read about involves either stolen credentials or compromised credentials. If your authentication is just passwords, you're betting your organization's security on something consistently proven weak.
The answer is multi-factor authentication, which adds a second layer of proof. If you know someone's password and you try to log in, the system asks for something additional—a code from an authenticator app, a push notification to their phone, a hardware security key, something that proves they physically have access to that second factor. Even if someone steals the password through phishing, they can't access the account without the second factor. The attacker would need to compromise multiple different proof types, which is exponentially harder than stealing a single password.
Multi-factor authentication comes in different forms. Time-based one-time passwords—apps like Google Authenticator or Authy that generate a new code every 30 seconds—work offline but require the user to manually type the code. Push notifications to a smartphone are more user-friendly but depend on the user having that specific phone. Hardware security keys are the most secure but require users to carry an additional device. SMS text message codes are better than nothing but can be intercepted or redirected through SIM swapping attacks. The practical tradeoff is between security and usability: hardware keys are most secure but users resist them, push notifications balance both, time-based apps are acceptable but users sometimes lose access to them, and SMS is weak but nearly universal.
What matters is that authentication is the foundation for everything else. If the first layer fails, access control doesn't matter because attackers already have legitimate credentials. If the first layer is strong—password plus a second factor—then the security depends on what you do with that verified identity.
Authorization: Determining What Verified Users Can Do
Once you've verified someone is who they claim, authorization determines what resources that person can access and what actions they can perform. This is where the complexity starts multiplying. A user proves their identity by logging in, and the system then checks: what systems can this user access, what data can they read or modify, what administrative functions can they perform?
Authorization without authentication is useless because you're not sure who you're authorizing. But authentication without authorization is equally broken because you might as well have no security controls at all—anyone who authenticates can access everything. Both layers are essential and they work together.
The challenge with authorization is that permissions compound over time. When someone joins the organization, they get access to the systems they need for their role. When they move to a different role, they often keep their old access while gaining new access. When they leave the organization, some access gets revoked but other access—especially to shared resources, legacy systems, or forgotten projects—might remain. Over years, this permission accumulation creates a situation where the access people have bears no relationship to the access they actually need.
Authorization works at different scales. In a small organization with 20 people, you might manage access individually: user Jane needs access to the accounting system, user Bob needs access to the customer database. This is granular but becomes unmaintainable fast. As organizations grow, you need models that scale, which leads to role-based systems where you define roles like "Financial Analyst" or "Customer Support Representative" and assign users to roles rather than managing permissions individually.
What's important to understand is that authorization is an ongoing negotiation. You need to give people enough access to do their jobs effectively—if the approval process for access is too restrictive, people work around the system or call your IT team every time they need something. You need to restrict access to things they shouldn't touch—if authorization is too loose, you violate least privilege and create risk. Finding that balance is the practical work of access control.
Identity Governance: Keeping Access Aligned with Reality Over Time
This is the layer where most organizations fail, and it's where real security lives. Identity governance is the process that keeps access correct as the organization changes. When someone is hired, governance provisions access. When they move roles, governance updates their access. When they leave, governance revokes everything immediately. Without governance, access entropy accelerates until your access control system is theater that no one relies on.
Consider a typical scenario without formal governance. Someone is hired as a customer support representative. IT manually creates an account and adds them to the customer support group. Three months later, they're promoted to team lead. Someone tells IT about it, but the person never gets removed from the customer support group while being added to the team lead group, so now they have both sets of permissions. A year later, they move to a different department. Again, the old groups aren't removed. A year after that, they leave the company. The company terminates their employee account, but they still have access to the customer database through the old customer support group account that was never cleaned up. Data leaks. Incident investigation reveals that the employee technically still had access.
This scenario repeats across every organization without formal identity governance. The solution is straightforward: define who does what at each stage of the employee lifecycle and formalize the process.
Onboarding should follow a workflow. HR notifies the identity system that a new employee is starting. The system looks up their role, department, and location, then provisions or requests provisioning of appropriate access. This creates a record of what was provisioned and why. Role changes should go through the same workflow: request, approval, access provisioning, and most importantly, removal of old access. Offboarding should be fast and complete: on the employee's last day, all access should be revoked immediately, not days or weeks later.
The layer that makes governance work is access reviews. At least annually—ideally quarterly—managers should review what access their team members have and confirm they still need it. This catches several common problems: access from previous roles that was never revoked, access for projects that ended, access that was granted "temporarily" but forgotten. Access reviews are tedious and most organizations do them poorly, but reviews are the only mechanism that catches permission drift. Without reviews, access entropy is guaranteed.
Access Control Models: Implementing Authorization at Scale
Organizations implement authorization through different models, and the model you choose affects how sustainable your access control system is. The most common is role-based access control, where you group permissions into roles—Financial Analyst, System Administrator, Customer Support—and assign users to roles rather than assigning permissions directly.
Role-based access control works because it maps to organizational structure. Most organizations already think in terms of roles and job titles. A Financial Analyst role includes permissions to access the accounting system, general ledger, and financial reports. When someone becomes a financial analyst, they get assigned to that role and inherit those permissions automatically. When their role changes, they lose those permissions. Managing five roles is far more sustainable than managing permissions individually for hundreds of users.
The complexity comes in role design. Too many roles—200 roles for a 500-person organization—and the system becomes unmaintainable. No one remembers why half the roles exist or what permissions they should have. Too few roles—five roles for a 500-person organization—and people end up with far more access than they need because their actual job responsibilities don't fit neatly into a simple role structure. Role design requires understanding how your organization actually works and grouping permissions in ways that match real job functions.
Separation of duties is another critical consideration in role design. In financial systems, the person who can approve payments shouldn't be the same person who initiates payments. In security systems, the person who can change audit logging shouldn't also be able to modify other system configurations. Certain roles should never be combined because combining them would let someone commit fraud or cover it up. Good role-based access control bakes these business rules into the role structure.
Other access control models exist for specific needs. Attribute-based access control makes decisions based on properties of the user, the resource, and the context. Instead of "Financial Analyst can access accounting reports," you might have "users in Finance can access accounting reports marked for Finance, only during business hours, from corporate IP addresses." This is more flexible but harder to audit and explain. Most organizations use role-based as the foundation with attribute or rule-based exceptions layered on top for edge cases.
Audit and Accountability: Proving That Decisions Were Made Appropriately
The final layer is proof. Audit and accountability mean comprehensive logging: who authenticated, when they authenticated, what they accessed, what changes they made. These logs serve multiple purposes. They're evidence for compliance audits—regulators want to see that you have access controls and that they're actually working. They're forensic information if something goes wrong—if you suspect someone misused access, the logs should show what they did and when. They're a deterrent—people behave differently when they know their actions are logged.
Logging without monitoring is theater though. Most organizations collect logs passively and never look at them until something breaks. The real security work is analysis: looking at the logs, identifying patterns that suggest problems, and responding to anomalies. A user who typically logs in from the East Coast suddenly logging in from Asia at 3 a.m. might be legitimate or might indicate a compromised account. A junior employee suddenly accessing administrative systems they've never accessed before might be appropriate or might be credential misuse. An application service account accessing data it shouldn't need is usually a misconfiguration but could be an attack.
Monitoring this happens in different ways. Small organizations might have security staff who periodically review logs. Larger organizations use security information and event management systems that collect logs centrally, apply rules to flag suspicious activity, and alert security teams. The method varies but the principle is the same: logs are only valuable if you're actually analyzing them.
Understanding these five layers—authentication, authorization, governance, access control models, and audit—gives you a framework for evaluating your identity security. Most organizations do some of this but miss the connections. They might have strong authentication but weak governance, leading to orphaned accounts. They might have good role-based access control initially but poor review processes, leading to permission drift. They might have comprehensive logging but never monitor it. The security is in the whole system, not any single piece.
Your next conversation should focus on which of these five layers is weakest in your environment and where to start improving. That's where your actual risk lives—not in the fancy authentication mechanism or the sophisticated role model, but in the day-to-day processes that keep access correct and the monitoring that proves decisions were appropriate.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about identity and access management as of its publication date. Standards and best practices evolve — consult a qualified compliance professional for guidance specific to your organization.