Identity access management is how organizations control who can see what information and use which systems

Identity access management (IAM) is a set of processes and tools that organizations use to decide who gets access to what. When you log into your bank account, your employer's email, or a hospital patient portal, IAM is what's running in the background — checking that you are who you say you are, confirming you have permission to see those records, and logging what you did while you were there.

For you as a user, IAM matters because it's the difference between your data staying private and ending up visible to someone who shouldn't see it. A weak IAM system at a company means a disgruntled employee, a contractor, or someone who stole credentials could access customer records, financial data, or health information. A strong one means access is tied to your actual job, gets removed when you leave, and leaves a trail if something goes wrong.

You don't manage IAM yourself — the organization does. But understanding how it works helps you spot when something is off, know what to expect when you change jobs or roles, and understand why some companies ask for more verification than others.

Key Takeaways

  • IAM has three parts: proving who you are (authentication), confirming you have permission (authorization), and recording what you did (accounting).
  • When you change jobs or roles within a company, IAM should automatically remove your old access and grant new access — if it doesn't, old access can linger for months.
  • A strong IAM system requires more than a password: multi-factor authentication, role-based permissions, and regular audits of who has access to what.
  • If you notice you still have access to systems after leaving a job or changing departments, report it to your IT department immediately.

The three parts of identity access management

Authentication is proving you are who you claim to be. This is usually a username and password, but stronger systems add a second factor — a code from an authenticator app, a text message, a fingerprint, or a security key. The more sensitive the data, the more factors you should see.

Authorization is the permission check that happens after you've proven who you are. Just because you logged in doesn't mean you can see everything. A payroll clerk at a hospital can access salary information but not patient medical records. A nurse can see a patient's medications but not their financial records. IAM enforces these boundaries by assigning each person a role — like "manager," "employee," or "contractor" — and tying permissions to that role.

Accounting (sometimes called auditing) is the record-keeping part. Every time you log in, every file you open, every change you make — it gets logged. If something goes wrong, the organization can trace who did what and when. This is especially important in healthcare, finance, and government, where regulations require a full audit trail.

Why organizations use role-based access instead of individual permissions

When a company has 500 employees, it would be impossible to set permissions one person at a time. Instead, IAM systems use role-based access control (RBAC). Everyone in the same job gets the same permissions. A software developer gets access to code repositories and testing servers. A human resources person gets access to hiring systems and employee records. A receptionist gets access to the calendar and visitor log.

When you change roles, the system should automatically remove your old permissions and grant new ones. In practice, this doesn't always happen smoothly. Someone might forget to remove you from the old system, or the systems don't talk to each other, so your access lingers. This is why security audits exist — to catch people who still have access they shouldn't.

Role-based access also makes it easier to spot problems. If a developer suddenly has access to payroll data, that's a red flag. If a contractor has the same access as a full-time employee, that's worth questioning. The clearer the roles, the easier it is to notice when something is wrong.

What happens when you start or leave a job

On your first day, IAM creates an account for you and assigns you a role based on your job title. Your manager might request specific access — to certain projects, certain folders, certain systems — and IAM grants it. This should happen within hours or a day. If you're waiting more than a few days for basic access, something is slow.

When you leave, IAM should disable your account and remove all access. In a well-run organization, this happens on your last day or within 24 hours. In a poorly-run one, it can take weeks. In the worst cases, it never happens — people have found they still had access to their old company's systems months or years after leaving. This is a security risk for the company and a liability for you, because anything done with your credentials looks like you did it.

If you change departments or roles, the same process should happen: old access removed, new access granted. Ask your IT department to confirm both parts happened. If you still have access to your old department's systems after moving, report it.

Multi-factor authentication as part of IAM

A password alone is not enough for sensitive systems. If someone steals your password — through phishing, a data breach, or malware — they can log in as you. Multi-factor authentication (MFA) adds a second check: even if they have your password, they can't get in without a code from your phone, a fingerprint, or a security key.

Many organizations now require MFA for email, financial systems, and healthcare portals. Some require it only for remote access or for users with high-level permissions. The more sensitive the data, the more factors you should expect to see. If your bank only asks for a password, that's a sign their IAM is weak.

You control one part of MFA: keeping your second factor secure. If your authenticator app is on your phone and your phone is stolen, someone could bypass MFA. If you use text message codes and someone can intercept them (rare but possible), they could get in. Security keys — physical devices you plug in or tap — are harder to compromise, which is why they're becoming more common for high-security accounts.

How IAM protects you from insider threats

Not all security breaches come from outside hackers. Sometimes the threat is someone inside the organization — a disgruntled employee, a contractor with too much access, or someone who was fired but still has credentials. A strong IAM system limits the damage an insider can do.

If access is tied to your specific role and job, you can only see what you need to do your work. A customer service representative can't access the source code. A developer can't access customer payment information. If someone tries to access something outside their role, the system can flag it or block it.

The accounting part of IAM is what catches insiders after the fact. If someone downloads a large amount of data before quitting, the audit log shows it. If a contractor accesses files they shouldn't, it's recorded. This doesn't prevent the breach, but it makes it detectable and traceable.

What can go wrong with IAM and what to watch for

The most common IAM failure is access creep — people accumulate permissions over time and never lose them. You get access to one project, then another, then you move teams but nobody removes the old access. After a few years, you have access to things you shouldn't. This is why organizations do periodic access reviews, where managers confirm that each person still needs the access they have.

Another common problem is orphaned accounts — accounts that belong to people who no longer work there. A contractor finishes a project but their account stays active. Someone is fired but their email still works. These accounts are security risks because anyone who knows the password can use them, and the organization won't notice because nobody is supposed to be using them.

A third problem is weak authentication. Some organizations still rely on passwords alone, or they allow weak passwords, or they don't enforce MFA. If you're asked to set up an account at a company and they don't require a strong password or offer MFA, their IAM is not strong.

If you notice you still have access to systems after leaving a job, changing roles, or finishing a contract, report it immediately. Don't assume it will be caught. It's your responsibility to flag it, and the organization's responsibility to fix it.

Frequently Asked Questions

Can I see what access I have to company systems?

Yes. Ask your IT department or your manager for a list of systems you have access to. Some organizations have a self-service portal where you can see this yourself. If you can't get a clear answer, that's a sign the organization doesn't have good visibility into its own IAM.

What should I do if I think someone else is using my account?

Tell your IT department immediately. Change your password, enable MFA if it's not already on, and ask them to review the audit log for your account. They can see what was accessed and when, which will show if someone else logged in.

Why does my company require different passwords for different systems?

Some organizations use a single sign-on system where one password works everywhere. Others require separate passwords for security or because their systems don't talk to each other. Separate passwords are more annoying but can be more secure if one system is breached — the breach doesn't compromise all your accounts.

What happens to my access if I take a leave of absence?

This varies by company. Some disable your access while you're gone and re-enable it when you return. Others leave it active. Ask your HR or IT department before you leave so you know what to expect and can request access be restored on your return date.

Is it normal for my company to audit who has access to what?

Yes, and it's a sign of good security practices. Regular access reviews catch people who have permissions they shouldn't have and catch orphaned accounts. If your company never does this, their IAM is weak.