Identity and access management is the discipline of making sure the right people, and only the right people, can reach the right resources, for the right reasons, at the right time. It is the control most incidents ultimately turn on, because a stolen or over-privileged identity is the key that opens every other door.
The framework rests on a simple chain: prove who someone is, decide what they may do, grant only that, and check later that the grant is still correct. Break any link and the others weaken, since strong authentication is wasted if everyone is an administrator, and least privilege is meaningless if identities are easy to impersonate.
This framework is reusable for any environment and aligns to recognized guidance, drawing on the digital identity guidance of NIST and the access control controls of established catalogs, without reproducing their text.
Every access decision starts with an identity, and every identity has a lifecycle: it is created, it changes as a person's role changes, and it must be removed when they leave. Most access problems trace back to a lifecycle step that was skipped.
The critical events are joining, moving, and leaving. When someone joins, they should receive exactly the access their role needs, no more. When they move, old access should be removed as new access is added, not simply stacked on top. When they leave, access should be revoked promptly, because a departed employee with a live account is a standing risk that guards nothing.
Accumulated access, often called privilege creep, is the silent result of many moves without cleanups. Over years, a long-tenured employee can quietly gather the combined access of every role they ever held, which is exactly the concentration an attacker hopes to hijack.
An analyst joins in finance, moves to procurement after a year, then to a systems role. If each move only added access, they now hold finance approvals, procurement authority, and system administration at once, a combination no single job needs and no reviewer would grant on purpose. A single compromised session for that one account now spans three sensitive domains. The fix is not heroic: at each move, the mover process removes what the old role required before the new access is granted, so the account always reflects the current job and nothing more.
Authentication is proving that a person is who they claim to be. Its strength sets a ceiling on every access decision that follows, because a resource is only as protected as the login in front of it.
Proof draws on factors of different kinds: something you know such as a password, something you have such as a phone or hardware key, and something you are such as a fingerprint. Any single factor can be stolen or guessed, so combining factors, known as multi-factor authentication, is the single highest-value control most organizations can apply. It turns a stolen password from a full compromise into a failed attempt.
Passwords remain common but are the weakest factor, because people reuse them and attackers harvest them at scale. Modern guidance favors longer passphrases over forced complexity, discourages routine forced rotation that pushes people toward weak patterns, and pushes toward phishing-resistant methods where possible. The direction of travel is to lean less on the secret a user remembers and more on the device they hold.
Once identity is proven, authorization decides what that identity may do. The governing principle is least privilege: grant only the access a role genuinely needs, and nothing more, because every unused permission is a risk with no benefit.
Role-based access is the practical way to apply this at scale. Instead of granting permissions to people one by one, you define roles that bundle the access a job needs, then assign people to roles. This makes access reviewable, because a reviewer can reason about a handful of roles rather than thousands of individual grants, and it makes the joiner and mover processes clean.
The most powerful accounts, administrators and service accounts, deserve the tightest control, because their compromise is the most damaging. Good practice separates everyday work from privileged work, grants elevated access only when needed and for a limited time, and records what privileged accounts do. Standing, always-on administrative rights are a large target that is rarely justified.
Service accounts deserve a special mention because they are so often forgotten. They are non-human identities that let systems talk to each other, they frequently hold broad access, and because no person logs into them, their passwords are rarely changed and their activity is rarely watched. That combination, high privilege and low scrutiny, makes them a favored path for attackers, so they need owners, rotated credentials, and monitoring just like the human accounts, and arguably more.
Access granted correctly today drifts out of correctness over time. Recertification is the periodic check that every grant is still justified, and it is the control that catches the privilege creep the lifecycle process misses.
In a recertification cycle, the owner of a system or role reviews who has access and confirms, with evidence of the business need, that each grant should remain. Anything that cannot be justified is removed. The discipline that makes this real is that the reviewer must actively confirm each access, because a review where everyone clicks approve without looking is worse than none, since it launders stale access as if it were checked.
Two design choices make recertification effective rather than ritual. First, present the reviewer with the smallest useful unit, one person's access or one role's members, with enough context to judge, rather than a spreadsheet of thousands of lines that guarantees rubber-stamping. Second, make removal the easy default and retention the deliberate choice, so an access that the reviewer cannot quickly justify falls away rather than surviving by inertia. Framed this way, the review actively shrinks access over time instead of merely blessing whatever exists.
Identity controls rest on a small set of clear policies that state the rules everyone must follow. A policy is not paperwork for its own sake, it is the agreed answer to a recurring question, written down so it is applied the same way every time.
The policies most tied to access are the account and password rules, the acceptable-use rules, and the third-party access rules. Each turns a principle into a specific, enforceable requirement, and each names an owner responsible for keeping it current. A policy nobody owns is a policy that quietly goes out of date.
Policies work only when people know them, which is why awareness matters as much as the document. A rule that lives in a folder nobody opens protects nothing, so the policy has to be communicated, understood, and reinforced.
Identity health can be measured, and a few honest metrics tell you whether the controls are actually holding or merely written down. Each should point to a specific fix rather than a general unease.
These are chosen because each reveals a real weakness when it slips. Privileged accounts without strong authentication are the highest-value targets left exposed, a slow time-to-revoke means departed people keep live keys, and overdue recertification means access is drifting unchecked. A dormant-account count is a useful fourth, since unused live accounts are pure attack surface.
Identity and access management protects everything else by ensuring only the right people reach the right resources, proven, granted least, and reviewed.
Alghamdi, S. A. (2026). Identity, Access & Security Policies. saif3li.com. https://saif3li.com/en/articles/cybersecurity-identity-access-management
Part of The Library: essays and book summaries, deposited as https://doi.org/10.5281/zenodo.22974909
© 2026 Saif Ali Alghamdi. Licensed under CC BY-NC-ND 4.0. Share it unchanged with attribution and a link to the source. No commercial use, no derivative versions. Licence text