Identity & Access Management (IAM)

Perimeter security assumed there was a perimeter. There isn’t. What remains is identity — and identity is now the primary attack vector in the majority of breaches.

What It Actually Is

Identity and Access Management is the discipline of ensuring that the right entities — users, systems, and services — have the right access to the right resources, and that this access is continuously verified, minimally privileged, and revocable. It encompasses authentication (proving who you are), authorization (determining what you can do), and the governance processes that keep both aligned with actual business need over time. IAM is not a product category. It’s an operational discipline supported by a stack of technologies: identity providers, single sign-on, multi-factor authentication, privileged access management, directory services, and increasingly, identity threat detection and response. The technology is table stakes. The discipline is what most organizations are missing.

Why Identity Is the Primary Attack Vector

The shift is structural. When most systems lived inside a corporate network, attackers needed to breach the perimeter first. Now that applications are SaaS, infrastructure is cloud, and users are everywhere, valid credentials provide direct access — no network breach required. The data reflects this. The majority of breaches now involve compromised credentials. Phishing delivers credential theft at scale. Infostealers harvest session tokens from endpoints. Initial access brokers sell valid VPN credentials on criminal marketplaces. Attackers don’t break in — they log in. This means that the quality of your IAM program is directly correlated with your breach likelihood. An organization with strong MFA, minimal standing privileges, and continuous access review is materially harder to breach than one with password-only authentication, broad standing access, and annual access reviews. The technology exists to close that gap. The organizational will to implement it consistently is where most programs fail.

The Core Components

Authentication strength. Passwords alone are not authentication — they’re a single factor that is routinely compromised. MFA is the minimum viable standard, but not all MFA is equal. SMS-based MFA is vulnerable to SIM swapping. Push notification MFA is vulnerable to fatigue attacks. Phishing-resistant MFA — hardware keys, passkeys, certificate-based authentication — is the standard that adversaries cannot currently bypass at scale. The gap between “we have MFA” and “we have phishing-resistant MFA” is the gap between adequate and secure. Least privilege access. Every user, service account, and application should have the minimum access required to perform its function — nothing more. In practice, access accumulates. Users get promoted and retain their previous access. Projects end and service accounts persist. Contractors leave and accounts stay active. The result is an environment where the blast radius of any single compromised credential is far larger than it needs to be. Privileged access management. Administrative accounts are the highest-value target in any environment. PAM controls how privileged access is granted, used, and audited — just-in-time provisioning, session recording, credential vaulting, and approval workflows for sensitive operations. Organizations without PAM typically have standing admin access distributed across many accounts, many of which haven’t been used in months and will never be reviewed until after they’ve been exploited. Lifecycle management. Joiners, movers, and leavers. When an employee joins, their access should be provisioned automatically based on role. When they move to a different function, old access should be revoked and new access granted. When they leave, all access should be terminated — immediately, completely, and verifiably. Offboarding failures are among the most common IAM vulnerabilities. Former employees with active accounts, contractors with persistent access, and service accounts tied to departed individuals represent unnecessary exposure that accumulates silently over time. Access reviews. Even well-designed access provisioning drifts over time. Regular, automated access certification — where managers confirm that their team members’ access remains appropriate — is the control that catches accumulation before it becomes exploitable. Annual reviews are insufficient for sensitive systems. Quarterly or continuous review, with automated revocation for unconfirmed access, is the standard for high-risk environments.

The Non-Human Identity Problem

Most IAM programs are designed around human users. The fastest-growing identity problem is non-human. Service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, cloud IAM roles, and machine-to-machine certificates now outnumber human identities in most enterprise environments by a significant margin. These identities are frequently over-privileged, rarely rotated, often undocumented, and almost never reviewed. When a developer hardcodes an AWS access key in a public GitHub repository, that’s an IAM failure. When a CI/CD pipeline has production write access it hasn’t needed in six months, that’s an IAM failure. The blast radius from a compromised service account with broad cloud permissions can exceed that of any individual human account. Mature IAM programs apply the same principles — least privilege, lifecycle management, rotation, monitoring — to non-human identities as to human ones. Most organizations are years behind on this.

Identity Threat Detection and Response

IAM isn’t just provisioning and governance — it’s also detection. Behavioral anomalies in identity data are often the earliest signal of an active attack. Impossible travel. Authentication from a new country. Privilege escalation by an account that’s never used admin functions. Bulk data access outside normal working hours. Mass OAuth grants to a third-party application. Identity Threat Detection and Response (ITDR) is the emerging practice of monitoring identity infrastructure for these signals and responding to them in the same way a SOC responds to endpoint or network alerts. Your identity provider generates an enormous volume of log data. Whether that data is being used for detection is a different question entirely.

Where IAM Connects to the Broader Program

IAM is a discovery input for CTEM — identity exposures (overprivileged accounts, stale credentials, misconfigured OAuth grants) are exposures in the same sense that unpatched vulnerabilities are. They need to be scoped, discovered, prioritized, and remediated within the same operational cycle. Zero Trust Architecture is built on IAM as its foundation. You cannot implement “never trust, always verify” without a robust identity layer that can actually verify. ZTA without mature IAM is a marketing position, not a security architecture.

Actionable Takeaways

Pull the list of accounts with administrative privileges in your environment and identify how many have been used in the last 30 days. The ones that haven’t been used are standing attack surface. Every dormant admin account is a credential an attacker can compromise and use without triggering behavioral anomalies — because the baseline for that account is silence. Ask your team how long it takes to fully deprovision access for a departed employee across all systems — not just Active Directory, but SaaS applications, cloud consoles, VPN, and shared credentials. If the answer is measured in days, or if “all systems” isn’t actually verifiable, you have an offboarding gap that former employees, their future employers, and attackers all benefit from.