Identity and access management (IAM) is a framework of policies, processes, and technologies that governs who can access what resources within an organization's systems and under what conditions. It covers the full identity lifecycle: creating accounts, assigning permissions, authenticating users, and revoking access when roles change or employees leave. Per NIST, IAM broadly refers to "the administration of individual identities within a system" to ensure that the right people have the right access to the right resources at the right time.
Identity and access management is how you answer the question: who is allowed in, and what are they allowed to do? That sounds simple until you count up every user account, service account, API key, role assignment, and SaaS integration in a growing startup, then multiply by the number of times someone joined, changed roles, or left the company without their access being revoked.
IAM covers two closely related functions. Identity management handles the lifecycle of accounts: provisioning new users, maintaining credentials, and deprovisioning access when someone leaves. Access management handles authorization: determining which systems, data, and actions an authenticated user can reach. Together, they enforce what security frameworks call the principle of least privilege, the idea that every account should have the minimum permissions needed to do its job, and nothing more.
IAM applies to human users and to machines. Service accounts, API tokens, CI/CD pipeline credentials, and cloud IAM roles are all part of the same problem. A credential is a credential regardless of whether a person or a service holds it.
IAM is not a single product. It's a set of capabilities that may be implemented through dedicated tools, cloud provider features, or a combination.
Verifying that a user is who they claim to be. Authentication methods include passwords, multi-factor authentication (MFA), single sign-on (SSO), and hardware security keys. MFA is the most impactful individual control: the Verizon 2024 Data Breach Investigations Report found that credential misuse is involved in nearly 40% of breaches, the top vector by a wide margin.
Determining what an authenticated identity can do. Authorization models include role-based access control (RBAC), where permissions are assigned to roles and users are assigned to roles, and attribute-based access control (ABAC), where permissions depend on attributes of the user, resource, and environment. Principle of least privilege lives here.
Creating accounts when someone joins, updating permissions when roles change, and removing access when someone leaves. Deprovisioning failures are one of the most common IAM gaps in small organizations. Orphaned accounts for former employees or contractors are a persistent source of unauthorized access risk.
Controlling and auditing access to high-privilege accounts, such as administrator credentials, production database access, and cloud root accounts. Privileged accounts warrant tighter controls, including time-limited access, session recording, and just-in-time provisioning.
Periodic reviews of who has access to what, and whether that access is still appropriate. Most compliance frameworks require formal access reviews at least annually. Fencer's identity and access security capability automates evidence collection for these reviews.
IAM is foundational to Zero Trust architecture. Zero Trust operates on the principle of "never trust, always verify": no user or device is inherently trusted, even inside the network. Every access request is evaluated based on identity, device posture, and context. IAM is the layer that establishes and verifies identity. Without strong IAM, including MFA, least privilege, and continuous access review, Zero Trust is aspirational rather than operational.
Fencer's identity and access security capability centralizes user access reviews across your connected SaaS tools and cloud environments, automating the evidence collection that compliance frameworks require. Instead of manually pulling user lists from each system before an audit, Fencer surfaces who has access to what, flags excessive privileges and dormant accounts, and generates the access review documentation your auditor expects. For startups preparing for SOC 2 or ISO 27001, this replaces a recurring manual fire drill with a continuous, auditable process.
Authentication answers "who are you?" (verifying identity). Authorization answers "what can you do?" (enforcing permissions). In practice: logging in with your password and MFA is authentication. Whether you can access the production database after logging in is authorization. Both are IAM functions, but they're implemented differently. Authentication is typically handled by an identity provider (IdP) or SSO solution. Authorization is enforced by your applications, cloud policies, and access control configurations. Getting one right doesn't automatically fix the other.
Most compliance frameworks (SOC 2, ISO 27001) require formal access reviews at least annually, with some requiring quarterly reviews for high-privilege access. In practice, smaller teams should do access reviews more frequently than large enterprises, not less, because access hygiene degrades faster in fast-changing organizations. When your company is growing, people are changing roles and leaving constantly. A quarterly review of who has admin access to your production systems is not excessive; it's how you catch the contractor whose access was never revoked six months ago.
Yes, but it requires intentional defaults from the start. The highest-impact steps don't require security expertise: enforce MFA on all accounts (especially cloud consoles and code repositories), use an SSO provider to centralize authentication, assign roles based on job function rather than copying existing users, and conduct a quarterly sweep of who has admin access. The failure mode isn't lack of tools; it's lack of process. Auditors evaluating SOC 2 controls are not expecting enterprise-grade PAM from a 15-person startup. They're expecting evidence that you thought about access deliberately and documented it.
