Knowledge · IT · Data · DX

IAM · Account & Access Management

Identity and Access Management

📂IT · Data · DX⏱2 min read📊Practical🔗7 related

What is IAM?

In one line
Short for Identity and Access Management: a framework that defines, per account, who can access which systems, and manages the lifecycle of access rights from hire to departure.
⚡ Summary in 3 lines
  • One process from account creation to revocation
  • Least privilege and role-based access control are the core
  • Leavers and shared accounts are the most common gaps

With IAM in place, the owner of account management changes. Before, each system administrator created and deleted accounts based on emails or verbal requests; once the framework is set, HR data determines account status. When an HR event occurs — hire, transfer, leave of absence, departure — the access linked to it is granted or removed automatically. The real change is that work that depended on one person's memory and personal ties moves to rules and records.

In practice, access management has three layers: general employee accounts; privileged access management (PAM) for administrators of servers and databases who can reach an entire system; and access auditing, which documents who holds which permissions and why. Even when you group access by role, management breaks down if roles multiply to match the number of job functions, so consolidate to 20–30 roles or fewer and handle the rest with time-limited temporary access. Without hard numeric criteria — such as auto-locking accounts unused for 90 days, disabling accounts on the day someone leaves, and retaining privileged-account activity logs — the framework exists only on paper.

Unified authentication (SSO) is part of IAM, not all of it. SSO only reduces the number of login screens to one; it does not touch the scope of permissions attached to the account. In fact, layering SSO on top without cleaning up permissions creates a structure where one door opens every room, so a single compromised account does far more damage. In rollout order, role cleanup, multi-factor authentication, and segregation of duties that stops one person from both placing and approving purchase orders come first.

The most common misconception is that buying a solution cleans up permissions. In reality, you end up carrying messy permissions over unchanged. Temporary permissions cause trouble even more often. If a request like “Just for this urgent closing, copy the team lead’s permissions as they are” is approved with no expiry date, two years later nobody notices when that employee opens closing data from another department. Access reviews also become a formality if department heads just sign the list, so it is safer to rerun the review for any department with zero revocations.

Courses that cover this term · AI & DX
Recommended courses · Recommended instructors · Quick quote
🧮 Mini quote · Based on instructor fees
About KRW 1.2 million (≈ US$900)2-hour talk · up to 20 people · Korean
Get a quote for these requirements →
💡 In plain English
It works like managing building access cards. Security depends less on issuing cards than on collecting them from people who have left.
Why it matters in practice
Many security incidents start not with an intrusion but with permissions that were left behind. Accounts are harder to delete than to create.
Origin and sources

Saltzer and Schroeder introduced the principle of least privilege in their 1975 paper on protecting computer systems. It has since become a basic principle of access control theory and corporate account management.

Source · Saltzer & Schroeder, “The Protection of Information in Computer Systems” (1975)
An example

Company A, a Korean auto parts maker with 620 employees and KRW 240 billion (≈ US$179,560,100) in revenue, had grown to 27 production, procurement, and quality systems. After a prime contractor's security audit flagged that 'accounts of former employees are still active', it spent four months rebuilding its account framework. (Hypothetical example)

  1. When the head of information security downloaded the accounts from all 27 systems and checked them against the HR roster, there were 620 active employees but 1,142 accounts, and 184 of them belonged to former employees.
  2. When an HR manager said, “I thought offboarding was handled in our collaboration suite,” the team agreed on the spot to a rule that automatically locks every account on the employee’s last day.
  3. Over 3 weeks, we brought together 12 line-of-business team leads and iterated on grouping 41 job functions into 9 roles, then agreed to accept exception requests only as temporary access of up to 30 days.
  4. The 46 admin accounts for servers and ERP were separated from personal accounts and changed to open for only 4 hours after approval, with every work session recorded and kept for six months.
  5. At the first quarterly review, the procurement team lead asked, “This person moved to logistics last year, so why do they still have ordering rights?” and revoked 11 permissions in their own department.
  6. At the six-month check, unrevoked accounts of former employees had fallen from 184 to 2. Revoking access after someone left, which used to take an average of 11 months, now happens the same day, and password reset requests dropped from 90 to 23 a month.
Related terms
Training linked to this term
📚Digital LiteracyNanum Consulting corporate training · On-site or onlineView course →
Need in-house training on this topic?
Get a curriculum and quote tailored to your needs right away.
Ask About Training
Last updated 13 Sep 2026 · Reviewed by John Kim

FAQ

Authentication is the process of verifying who you are; authorization is the process of allowing what that person can do. Logging in is authentication; whether you can open a particular folder is authorization.
Temporarily, yes. So the balance is struck by granting permissions only when needed and revoking them automatically, or by designing standard permission bundles well on a role basis.
Without individual accounts, you can't trace who did what, so investigation and accountability are impossible after an incident. If unavoidable, keep a usage log, but replace shared accounts with personal accounts and granted permissions wherever possible.
It depends on organization size and regulatory level, but quarterly or semiannual is typical. What matters more than the frequency is whether access is actually revoked; reviewing without cleaning up becomes a mere formality.