Identity and Access Management Reference Guide
CISSP Domain 5 · 6 topics · Concepts, real-world examples, and controls
Access control is the implementation of the least privilege principle across every category of asset an organization manages. It is the mechanism that translates “this person should be able to do this” into an enforced, auditable technical reality. The six asset categories below each require distinct control mechanisms — a single unified access policy cannot address them all.
Information
Data at rest and in transit. Access controlled by classification level, data ownership policy, and need-to-know. Encryption as a compensating control when access controls cannot be enforced at the media level. DLP as a detective and preventive control for data movement.
Systems
Servers, databases, network devices. Access via privileged access management (PAM), just-in-time provisioning, session recording. Administrative access is the highest-risk access — privileged accounts must have the most rigorous controls.
Devices
Laptops, mobile devices, IoT. Device identity verification (certificates, MDM enrollment) before network access. Full-disk encryption for data-at-rest protection if device is lost. Remote wipe capability for mobile devices with sensitive data.
Facilities
Physical spaces. Badge access, biometrics, mantrap entry, visitor management. Physical access logs must be correlated with logical access logs — an employee badging into the building at 2am who also logs into the financial system is a detection opportunity only if both logs are available.
Applications
Business applications, SaaS, internal tools. Role-based access within applications. SSO for consistent authentication. Application accounts must be provisioned and deprovisioned in sync with HR systems — not managed independently.
Services
APIs, microservices, cloud services. Service-to-service authentication via API keys, OAuth 2.0 client credentials, or mTLS. Service accounts must be inventoried, have minimal permissions, and rotate credentials on a defined schedule.
🌐 Real-world example — siloed access control
The 2016 Yahoo breach (affecting 3 billion accounts) included a failure of access control correlation: a “state-sponsored actor” had persistent access to Yahoo’s systems for years. Yahoo’s access controls for information, systems, and applications were managed in separate silos with no unified monitoring. An insider threat or persistent attacker with legitimate credentials in one system could move to others without triggering cross-system anomaly detection. Unified identity governance — a single source of truth for what every identity can access across all six asset categories — would have made the persistent access visible.
Design identification and authentication strategy
Authentication answers the question “are you who you claim to be?” It is the precondition for all authorization decisions. An authentication strategy that can be bypassed, replayed, or socially engineered renders every downstream authorization control irrelevant. Strong authentication is the single highest-ROI security control in modern environments — the majority of breaches involve compromised credentials.
Authentication factors
Multi-factor authentication (MFA) methods
SMS OTP
One-time code sent via SMS. Widely supported but the weakest MFA method. Vulnerable to SIM swapping, SS7 interception, and real-time phishing proxy attacks.
Avoid for high-value accounts. Better than no MFA but should be migrated to stronger methods.
Push notification
Authenticator app sends an approval request to the user’s phone. Convenient but vulnerable to MFA fatigue attacks — adversary sends repeated push requests until the tired user approves one.
Enable number matching and additional context in push notifications to prevent fatigue attacks (Microsoft Authenticator, Duo).
TOTP
Time-based One-Time Password (RFC 6238). Authenticator app generates a 6-digit code that changes every 30 seconds. Phishable in real-time (adversary relays code to legitimate site), but stronger than SMS.
Mitigate real-time phishing by using phishing-resistant MFA (FIDO2/passkeys) for privileged access.
FIDO2 / Passkeys
Cryptographic challenge-response tied to the specific origin (domain). The key pair is registered to a specific site — a phishing proxy on a different domain cannot use it. Phishing-resistant by design. Uses the device’s biometric or PIN as the unlock mechanism.
The gold standard for consumer and enterprise authentication. NIST SP 800-63B recommends phishing-resistant authenticators for high-assurance authentication.
Hardware tokens
Dedicated physical devices (YubiKey, RSA SecurID). FIDO2/U2F keys are phishing-resistant; TOTP tokens are not. Smart card certificates provide the strongest non-repudiation properties — used in government (CAC, PIV) and banking.
Most resistant to remote attacks. Physical loss is the primary risk — require reporting and immediate revocation procedures.
Passwordless
Eliminates the password entirely. Authentication via FIDO2 biometric, magic link to verified email/phone, or certificate-based auth. Reduces credential stuffing, password spray, and phishing attack surfaces simultaneously.
Microsoft, Apple, and Google are converging on passkeys as the cross-platform passwordless standard. NIST SP 800-63B Level 2 and 3 support passwordless phishing-resistant authenticators.
🌐 Real-world example — MFA fatigue attack
The 2022 Uber breach: the attacker purchased an Uber contractor’s credentials from the dark web, then launched an MFA fatigue attack — sending repeated Duo push notifications until the contractor, woken at 1am by repeated notifications, approved one. The attacker then gained access to Uber’s internal network. The attacker also impersonated Uber IT support via WhatsApp to socially engineer the approval. Duo’s number matching feature (which requires the user to enter the number shown on screen into the app, preventing blind approval) was not enabled. Post-incident, Uber mandated number matching across all MFA. The fix existed before the breach — it was simply not deployed.
Authentication strategy components
Select a component to see its definition and real-world implementation.
Single Sign-On (SSO)
SSO allows a user to authenticate once and access multiple applications without re-authenticating for each. Authentication is performed by a central Identity Provider (IdP); applications delegate authentication to the IdP rather than managing credentials themselves. Reduces password fatigue (fewer passwords = stronger passwords per system), centralizes authentication policy enforcement, and simplifies deprovisioning (disabling the IdP account immediately revokes access to all connected applications).
Security trade-off
SSO creates a single high-value target — the IdP account. Compromise of the SSO credential grants access to every connected application simultaneously. This makes MFA on the SSO credential non-negotiable and the IdP a critical infrastructure component requiring the highest security controls.
Real-world example
The 2023 Okta breach: attackers compromised Okta’s support system and used it to access customer tenants’ administrative consoles. Okta is a major SSO IdP used by thousands of organizations. When the support system was breached, the attacker could view authentication tokens and session data for customer organizations — effectively gaining SSO-level access to those organizations’ environments. The blast radius of an IdP breach extends to every customer application federated through that IdP. Okta customers with FIDO2/hardware token requirements were more protected than those relying on phishable MFA methods.
Federated Identity Management (FIM)
FIM extends identity trust across organizational boundaries. Rather than maintaining separate accounts in each partner organization’s systems, a user’s identity established in their home organization (the Identity Provider, IdP) is trusted by partner organizations (Service Providers, SPs). SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC) are the protocols that implement federation. The trust is established through cryptographic assertions — signed tokens the IdP issues that the SP verifies.
Key protocols
SAML 2.0 — XML-based federation protocol; widely used for enterprise SSO to web applications. OAuth 2.0 — authorization framework (not an authentication protocol); grants delegated access to resources. OIDC — authentication layer on top of OAuth 2.0; provides identity tokens (JWT format).
Real-world example
When a user clicks “Sign in with Google” on a third-party application, OIDC federation is in action. Google is the IdP; the third-party application is the SP. The user authenticates with Google (not the application), and Google issues a signed ID token the application verifies. The application never sees the user’s Google password — it only receives a cryptographically verified claim that Google authenticated this user with this email address. If the user’s Google account is compromised, so is every OIDC-federated application — the trust chain is only as strong as the IdP.
Credential management systems
Credential management systems (password managers, enterprise vaults, privileged access management platforms) store, generate, and manage credentials securely — removing the human tendency to reuse weak passwords and write down complex ones. Enterprise PAM systems (CyberArk, Thycotic, BeyondTrust) additionally rotate credentials automatically, check out credentials to authorized sessions, and record all use.
Password vault essentials
Generates random, unique credentials for each system. Provides credentials at session checkout, not stored in configuration files or scripts. Rotates credentials on schedule or after each use (for privileged accounts). Audits every credential access. The vault’s master secret is the highest-risk credential in the environment — it must be protected with the strongest available controls (HSM-backed, requires multiple custodians for root access).
Real-world example
In the 2020 SolarWinds breach, investigators found hardcoded credentials in SolarWinds’ update server: the password “solarwinds123” was used to protect the update build server. This password was reportedly posted publicly on GitHub for months before the breach. A credential management system that generated and rotated credentials for build infrastructure would have prevented this specific vulnerability. Post-breach, CISA mandated that federal agencies use PAM tools for privileged credential management.
Just-In-Time (JIT) access provisioning
JIT access grants privileged access only when needed and for the minimum duration required — then automatically revokes it. Rather than administrators having persistent standing privilege (always-on admin rights that exist whether being used or not), JIT provides ephemeral privilege: an administrator requests elevated access for a specific task, it is granted (with approval if required), used, and then expires automatically after a defined window.
Security benefit
Persistent standing privilege is an attacker’s dream: any compromise of a privileged account grants immediate, unlimited access. JIT eliminates the standing privilege window — an attacker who compromises an account without an active JIT session gains only standard user access. They must additionally trigger a JIT request (which generates an alert) to gain elevated access.
Real-world example
Microsoft’s internal “Just Enough Administration” (JEA) and “Just-In-Time Administration” (JITA) programs implement JIT for Azure infrastructure management. Engineers have zero standing access to production. For each maintenance task, they request access to specific resources for a maximum of 8 hours via an approval workflow. All sessions are recorded. Microsoft’s internal security team reduced its privileged access standing footprint by over 90% through JIT implementation — dramatically reducing the value of any single compromised account.
Session management
Session management governs how authenticated sessions are created, maintained, extended, and terminated. After authentication, a session token represents the user’s authenticated state — its security properties determine whether the authentication investment is preserved or undermined. A strong authentication process followed by a weak session token is equivalent to a strong lock on a door with the key taped to the frame.
Session security requirements
Tokens must be cryptographically random (not predictable or enumerable); bound to context (IP, user-agent) to prevent theft and replay; transmitted only over TLS with secure and httponly flags; have defined expiry times appropriate to the sensitivity of the application; and be invalidated on logout (server-side invalidation — not just cookie deletion on the client).
Real-world example
The 2017 Equifax breach involved attackers maintaining persistent access for 78 days using session tokens obtained from the compromised web application. The application’s session tokens had no time limit and were not rotated after privilege changes — once obtained, a token was valid indefinitely. Continuous session validation (re-verifying the token’s validity against server-side session state on each request) and short absolute timeout periods (regardless of activity) would have invalidated the attacker’s sessions periodically, requiring re-exploitation to maintain access.
Registration, proofing, and establishment of identity
Identity proofing is the process of verifying that a claimed identity corresponds to a real, specific individual before issuing credentials. The strength of all subsequent authentication depends on the quality of initial identity proofing — if anyone can register as anyone, strong authentication merely proves “this is the person who enrolled under this identity,” not “this is the person they claim to be.”
NIST SP 800-63A identity assurance levels
IAL1 — No requirement to link claimed identity to a real person. Self-assertion acceptable. Suitable for low-risk applications. IAL2 — Evidence of real-world existence required (government ID). Remote or in-person verification. Suitable for most enterprise and government applications. IAL3 — In-person proofing with physical inspection of identity documents by a trained agent. Required for highest-assurance applications (e.g., issuance of federal credentials).
Real-world example
COVID-19 unemployment fraud in the US (2020–2021) resulted in an estimated $163 billion in fraudulent claims — the largest government benefits fraud in US history. State unemployment systems had IAL1 or weak IAL2 identity proofing: identity was verified by checking a Social Security Number against existing records, without verifying the claimant was actually that person. Fraudsters used stolen identities (purchased from breach data) to file claims at scale. ID.me and similar identity proofing services implemented IAL2 verification (government ID + facial matching) as a remediation — a control that should have been in place before billions were lost.
Federated identity with a third-party service
Federation extends the boundaries of identity trust to include external parties — cloud providers, SaaS vendors, partner organizations. The architecture of federation (on-premises IdP, cloud IdP, or hybrid) determines the control surface, the single point of failure, and the attack surface of the organization’s identity system.
On-premises identity federation
The organization maintains its IdP on-premises (Active Directory Federation Services, Shibboleth, PingFederate). SAML 2.0 tokens are issued by the organization’s own infrastructure, giving full control over issuance policy, token lifetime, and attribute claims. Cloud SaaS applications configured as SAML Service Providers trust tokens from the on-premises IdP.
Advantages
Full control of identity infrastructure. Tokens never leave the organization’s systems. Compliance with data residency requirements — identity data remains on-premises. No dependency on a third-party cloud IdP’s availability or security posture.
Disadvantages and risks
The on-premises IdP is critical infrastructure — its compromise or unavailability has immediate, wide-reaching impact. Requires significant operational overhead to maintain, patch, and scale. On-premises AD has been a primary target in numerous major breaches (Golden Ticket attacks, DCSync attacks against domain controllers).
Real-world example
The SolarWinds breach included the compromise of on-premises ADFS (Active Directory Federation Services) servers at multiple victim organizations. By stealing ADFS token-signing certificates, the attackers could forge SAML tokens for any user — granting access to every SAML-federated cloud application (Microsoft 365, Salesforce, ServiceNow) without going through the authentication process. The attack demonstrated that an on-premises IdP with a compromised signing key is a total identity compromise for all federated applications.
Cloud identity federation
Cloud-native IdPs (Microsoft Entra ID / Azure AD, Okta, Ping Identity cloud, Google Workspace) host identity infrastructure in the cloud. Organizations federate their applications — both cloud and on-premises — to the cloud IdP. Authentication flows through the cloud IdP regardless of whether the user or the application are on-premises.
Advantages
Elastic scale, automatic updates, no hardware to maintain, high availability SLAs (99.99% for major providers), built-in MFA and Conditional Access capabilities, native integration with cloud applications. Faster to deploy new application integrations. Geographic distribution provides resilience.
Disadvantages and risks
The cloud IdP becomes a critical dependency — its availability and security directly affect all federated applications. Third-party security posture is outside organizational control. Data residency concerns for identity attributes stored in cloud IdP. Vendor lock-in risk if migration away from the cloud IdP is required.
Real-world example
The 2023 Microsoft Entra ID (Azure AD) compromise by the Storm-0558 threat actor — later attributed to Chinese espionage — involved the theft of a Microsoft signing key that could forge authentication tokens for any Entra ID tenant. Multiple US government agencies’ Microsoft 365 email was accessed. The attack was discovered because one agency had Microsoft’s audit logging at a tier that captured the anomalous access — agencies on lower-tier licenses did not have the logging visibility to detect the compromise. Cloud IdP security is only as good as the provider’s controls — and the customer’s ability to detect anomalies requires appropriate logging tier.
Hybrid identity federation
Organizations maintain both on-premises Active Directory and a cloud IdP, with identity synchronization between them. Microsoft Entra Connect (formerly Azure AD Connect) synchronizes on-premises AD identities to Entra ID — users authenticate with on-premises credentials to access both on-premises and cloud resources. Password hash synchronization, pass-through authentication, and ADFS are the three hybrid connectivity options.
Architecture considerations
The synchronization mechanism (Entra Connect) becomes critical infrastructure — it runs with highly privileged access to both on-premises AD and cloud Entra ID. Compromise of the Entra Connect server provides a pivot point between on-premises and cloud environments. The security of hybrid identity is bounded by the security of the on-premises AD — a golden ticket attack on on-premises AD in a hybrid environment can be used to forge tokens that are accepted by cloud resources.
Real-world example
In multiple incident response engagements following on-premises Active Directory compromises, the responders found that attackers had pivoted from on-premises AD to Microsoft 365 by exploiting the hybrid identity synchronization. After compromising the on-premises AD, attackers added credentials to cloud-only accounts (which are not synchronized from on-premises) using the elevated permissions from the on-premises compromise. Remediating a hybrid identity breach requires simultaneous remediation of both on-premises AD and cloud Entra ID — an operationally complex process that many organizations underestimate.
Implement and manage authorization mechanisms
Authorization answers “what are you allowed to do?” — after authentication has answered “who are you?” Different authorization models enforce access at different levels of granularity, with different administrative overhead and different suitability for different environments. Selecting the wrong model creates either over-permissive access (too broad) or unmanageable complexity (too granular).
RBAC
Role-Based Access ControlAccess rights are assigned to roles, and users are assigned to roles. A user’s access is the sum of their roles’ permissions. Scalable — adding a new user requires only role assignment; changing a role’s permissions affects all users with that role simultaneously.
Best for: large organizations with well-defined job functions. “All Sales Managers can read customer data and write opportunity records.” Most enterprise applications implement RBAC natively. Weakness: role explosion — hundreds of roles that overlap and duplicate, creating unmanageable complexity.
MAC
Mandatory Access ControlAccess decisions are enforced by the system based on security labels — users cannot override them. The system compares the subject’s clearance level with the object’s classification and enforces Bell-LaPadula or Biba rules. No discretion for users or data owners.
Best for: government and military systems handling classified information. SELinux implements MAC in Linux. Windows Integrity Levels are a simplified MAC implementation. Weakness: inflexibility — legitimate business need for exceptions requires policy changes at the system level, not user level.
DAC
Discretionary Access ControlThe data owner determines who can access their resources. Access Control Lists (ACLs) on files and directories, where the owner can grant or revoke access at their discretion. Flexible — owners can share with whoever they choose. High operational risk: owners may grant excessive access.
Best for: collaborative environments where data owners need flexibility (file shares, SharePoint). NTFS permissions on Windows are DAC. Weakness: Trojan horse problem — a malicious program running with a user’s privileges can read and exfiltrate any data that user has discretionary access to.
ABAC
Attribute-Based Access ControlAccess decisions are based on attributes of the user, the resource, and the environment — evaluated against a policy. “A user with department=Finance AND clearance=Confidential can read documents with classification=Financial AND project=Q4-Budget.” Extremely granular and flexible.
Best for: complex environments with many contextual factors (healthcare, finance, government). AWS IAM policies are ABAC. Weakness: policy complexity — ABAC policies are powerful but hard to reason about and audit. A policy engine misconfiguration can silently grant or deny access incorrectly.
Rule-based AC
Rule-Based Access ControlSystem-enforced rules applied to all users — not role-specific. “No access between midnight and 6am.” “Access only from IP ranges in this list.” “No file downloads over 100MB.” Rules apply globally regardless of user identity. Firewall ACLs are the canonical rule-based control.
Best for: time-of-day restrictions, location-based restrictions, rate limiting, and network access policies. Firewall rules, router ACLs, and time-based access restrictions. Complements RBAC — RBAC defines who can do what; rule-based AC defines the conditions under which they can do it.
Risk-based AC
Risk-Based / Adaptive ACAccess decisions are adjusted dynamically based on calculated risk at the time of the request. Low-risk request (familiar device, known location, normal time) → no additional friction. High-risk request (new device, unusual country, suspicious behavior pattern) → step-up authentication or block.
Best for: consumer authentication, cloud access with diverse user populations, zero trust architectures. Microsoft Conditional Access, Okta Adaptive MFA. Real-world: when a user logs in from a country they have never been to, step-up MFA is required. When a user downloads 10x their normal data volume in one session, the session is flagged for review.
Policy decision and enforcement points
Policy Decision Point (PDP)
The component that evaluates access requests against policy and makes the allow/deny decision. In ABAC/XACML, the PDP evaluates attribute combinations against policy rules. In zero trust architectures, the control plane acts as the PDP — evaluating every access request against identity, device posture, and context signals.
Policy Enforcement Point (PEP)
The component that intercepts access requests, sends them to the PDP for decision, and enforces the result — granting or denying access to the resource. A firewall is a PEP. An API gateway is a PEP. A network proxy is a PEP. The PEP must be architecturally positioned so it cannot be bypassed — a PEP that can be circumvented provides no protection.
🌐 Real-world example — authorization failure (BOLA)
Broken Object Level Authorization (BOLA) — the #1 vulnerability in the OWASP API Security Top 10 — occurs when an API authenticates the caller but fails to verify they are authorized to access the specific object requested. The Facebook API (2019) returned any user’s private data when their user ID was passed to a specific endpoint — it verified the caller was authenticated but not that the caller owned or had rights to the requested user ID. 29 million accounts were affected. BOLA is an authorization failure, not an authentication failure. Every API endpoint must enforce authorization checks at the object level on every request — authentication alone is insufficient.
Manage the identity and access provisioning lifecycle
Identity is not a one-time provisioning event — it is a lifecycle that must be actively managed from creation to termination. Every phase introduces specific risks that compound over time if not addressed. Access accumulation, orphaned accounts, and unreviewed privileges are among the most persistently exploited vulnerabilities in enterprise environments.
Select a lifecycle phase to see its obligations and failure patterns.
Phase 1
Provisioning
Phase 2
Role transitions
Phase 3
Access reviews
Phase 4
Privilege escalation
Phase 5
Service accounts
Phase 6
Deprovisioning
Provisioning
Access provisioning must be driven by an authoritative HR system — not by ad hoc IT tickets or manager email requests. The joiner process assigns the minimum access required for the new role (least privilege at provisioning time), requires manager approval, and is documented. Access beyond the standard role profile requires a formal exception process with a documented business justification and time limit.
🌐 Real-world example
A major US retailer’s 2021 audit found that new employees in the finance department were being provisioned with access to 47 different applications — because the IT team copied the access profile of the previous employee in that role, who had accumulated access over 8 years. The “template” user had far more access than any specific role required. Provisioning from role profiles (defined by minimum required access) rather than from existing user profiles prevents day-one access accumulation.
Implement authentication systems
Authentication systems are the technical infrastructure that enforces identification and authentication policy. The gap between “we have a policy requiring MFA” and “our authentication system enforces MFA on every access path” is where most authentication failures occur. Authentication systems must cover every access path — not just the primary user interface.
Core authentication protocols and systems
Select a system to see how it works and where it is appropriate.
Kerberos
A ticket-based authentication protocol used in Windows Active Directory environments (and MIT Kerberos in Linux/Unix). A client authenticates to the Key Distribution Center (KDC) — which comprises the Authentication Server (AS) and Ticket Granting Server (TGS). The client receives a Ticket Granting Ticket (TGT), which it uses to request service tickets for specific resources. Passwords never travel over the network — only tickets and encrypted session keys.
Components
KDC — the trusted third party that issues tickets. In AD, the domain controller is the KDC. TGT — proves the user has authenticated; used to request service tickets. Encrypted with the KRBTGT account’s hash. Service ticket — permits access to a specific service. Encrypted with the service account’s hash.
Key attacks
Kerberoasting — requesting service tickets for accounts with SPNs and cracking them offline. AS-REP Roasting — requesting pre-authentication-exempt accounts’ encrypted AS-REP for offline cracking. Golden Ticket — forging TGTs using the KRBTGT hash, valid for any user to any service. Pass-the-Ticket — stealing and reusing valid TGTs or service tickets.
Real-world example
The NotPetya attack (2017) used a credential dumper (Mimikatz) to extract Kerberos tickets and NTLM hashes from memory, then used pass-the-hash and pass-the-ticket to authenticate to every reachable Windows system without knowing any passwords. A single compromised administrator credential provided Kerberos tickets that could authenticate to every domain-joined machine. Protected Users security group (prevents ticket caching in LSASS) and Credential Guard (virtualizes LSASS memory) are the primary mitigations against ticket theft from memory.
LDAP and Active Directory
LDAP (Lightweight Directory Access Protocol) is a protocol for querying and modifying directory services — the phone book of an organization’s identities, groups, and resources. Microsoft Active Directory (AD) is the dominant enterprise implementation of LDAP, extended with Kerberos authentication, Group Policy, and domain trust mechanisms. Almost every enterprise authentication system ultimately queries AD to resolve identities and group memberships.
Security considerations
LDAP traffic is unencrypted by default — LDAPS (LDAP over TLS, port 636) or LDAP with STARTTLS must be enforced to prevent credential interception during LDAP bind operations. AD’s attack surface is vast: domain controllers hold the master copy of all credentials; the KRBTGT account’s hash enables Golden Ticket forgery; replication traffic between DCs contains password hashes.
Real-world example
In the 2020 SUNBURST/SolarWinds breach, threat actors performed AD reconnaissance using LDAP queries to map the victim organization’s structure — identifying high-value targets (domain admins, service accounts) and trust relationships to adjacent domains. Standard LDAP queries authenticated as a normal user (already compromised) returned enough information to plan privilege escalation paths. AD monitoring tools (BloodHound / PlumHound equivalent in defensive mode) that visualize attack paths from current access to domain admin are essential for identifying exposure before attackers do.
RADIUS and TACACS+
RADIUS (Remote Authentication Dial-In User Service) and TACACS+ (Terminal Access Controller Access Control System Plus) are protocols for centralized authentication, authorization, and accounting (AAA) — primarily for network device access and VPN authentication. RADIUS combines authentication and authorization in a single response; TACACS+ separates them (more flexible). Both provide centralized logging of authentication events.
RADIUS vs TACACS+
RADIUS — UDP-based, encrypts only the password, combines AuthN+AuthZ. Widely supported — essentially every VPN, Wi-Fi controller, and network device supports RADIUS. TACACS+ — TCP-based, encrypts the entire payload, separates AuthN/AuthZ/Accounting. Preferred for network device (router, switch) administration because the separation of AuthN and AuthZ allows fine-grained command authorization. Cisco proprietary historically but now open.
Real-world example
In the 2023 Cisco IOS XE vulnerability exploitation (CVE-2023-20198), attackers exploited a zero-day to create local administrator accounts on Cisco devices. Organizations using TACACS+ for centralized network device authentication with command authorization could detect anomalous local account creation and unauthorized configuration changes — TACACS+ logs every command executed on every device. Organizations relying on local authentication with no TACACS+ centralization had no visibility into account creation until a scan revealed the implants weeks later.
OAuth 2.0 and OpenID Connect (OIDC)
OAuth 2.0 is an authorization framework — it enables a user to grant a third-party application access to their resources on another service without sharing their credentials. The user authorizes the application; the authorization server issues an access token the application uses to access the resource server on the user’s behalf. OAuth 2.0 alone does not provide identity — it provides delegated authorization.
OIDC extends OAuth 2.0
OpenID Connect adds an identity layer to OAuth 2.0 — in addition to the access token, the authorization server issues an ID token (JWT format) that contains claims about the authenticated user (sub, email, name, etc.). OIDC provides authentication; OAuth 2.0 provides authorization. Modern SSO implementations use OIDC for authentication and OAuth 2.0 for API authorization.
Real-world example
The 2023 GitHub OAuth token theft: Heroku and Travis CI had OAuth tokens that granted access to GitHub repositories on behalf of their users. When attackers stole these tokens, they could access private GitHub repositories for thousands of organizations — without knowing any user’s GitHub credentials. OAuth tokens with excessive scope (repository read/write on ALL repositories, not scoped to specific ones) and no expiry amplified the damage. OAuth tokens must be scoped to minimum required permissions and have defined expiry — treating them with the same care as passwords.
SAML 2.0
Security Assertion Markup Language 2.0 is an XML-based federation protocol for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). The IdP authenticates the user and issues a signed XML assertion; the SP validates the signature and grants access based on the assertion’s claims. SAML 2.0 is the dominant enterprise SSO protocol for browser-based applications.
Assertion types
Authentication assertion — confirms the user authenticated at the IdP at a specific time using a specific method. Attribute assertion — carries user attributes (name, email, department, role) from IdP to SP. Authorization assertion — carries access rights (rarely used in practice; most SPs determine authorization locally based on attributes).
Real-world example
The “Golden SAML” attack technique (discovered 2017, weaponized in SolarWinds 2020): if an attacker obtains the ADFS token-signing certificate’s private key, they can forge SAML assertions for any user to any SAML SP — gaining access to Microsoft 365, AWS, Salesforce, and any other SAML-federated application as any user, including global administrators, without triggering any authentication events. The IdP’s signing key is the crown jewel of a federated identity deployment. Token-signing certificates must be HSM-protected, rotated regularly, and any changes to them must generate high-priority alerts.
PKI and certificate-based authentication
Certificate-based authentication uses X.509 digital certificates — binding a public key to a verified identity — for authentication. The subject presents their certificate and proves possession of the corresponding private key via a cryptographic challenge. The relying party validates the certificate chain back to a trusted root CA. Used for smart card / PIV card authentication, mTLS (mutual TLS) for service-to-service authentication, and client certificate authentication in high-assurance environments.
Advantages over passwords
Not phishable — the private key never leaves the device (HSM or smart card). Provides non-repudiation — the authentication event is cryptographically tied to the certificate holder’s identity. Revocation via CRL/OCSP enables immediate invalidation if a certificate is compromised. Government PIV (Personal Identity Verification) and CAC (Common Access Card) cards implement certificate-based auth for physical and logical access.
Real-world example
US federal agencies implementing zero trust under OMB M-22-09 are required to use phishing-resistant MFA — which in practice means PIV/CAC certificate-based authentication or FIDO2 hardware tokens. Certificate-based authentication on smart cards has been the US federal standard since HSPD-12 (2004). The DoD’s CAC (Common Access Card) program — 4 million cards issued — provides certificate-based authentication for logical access to DoD systems, physical access to facilities, and digitally signed email. Physical smart card presence is required for authentication — a remote attacker with the user’s credentials cannot authenticate without the physical card.
The IAM security chain
Every gap in this chain is where identity becomes the attack vector — the entry point, the escalation path, or the persistence mechanism.
Prove identity before granting access
Identity proofing at registration. Strong authentication at every login. MFA required — phishing-resistant (FIDO2/passkeys) for privileged and high-risk access.
Centralize authentication through an IdP
SSO with a single IdP for all applications. Consistent policy enforcement. Immediate deprovisioning by disabling the IdP account.
Federate identity securely across boundaries
Protect IdP signing keys with HSMs. Monitor for anomalous token issuance. Hybrid environments inherit on-premises AD risk — remediate both simultaneously.
Authorize at the object level, not just the session
Authentication proves identity. Authorization must verify every specific action against every specific resource — BOLA is authentication success plus authorization failure.
Provision minimum access from day one
HR-driven provisioning from role profiles, not user templates. Least privilege at onboarding. Every exception documented with business justification and expiry date.
Review and recertify access regularly
Quarterly access reviews for privileged accounts. Annual for standard. Role transitions trigger immediate access recertification. Access accumulation is a slow-motion insider threat.
Eliminate standing privilege with JIT
No persistent admin rights. Privileged access provisioned on-demand, time-limited, and session-recorded. A compromised account without an active JIT session is a standard user.
Deprovision immediately and completely
Account disabled at the moment of separation — not after equipment return. All sessions terminated. All credentials rotated if shared. All tokens revoked. Orphaned accounts are open doors.
By profession, a CloudSecurity Consultant; by passion, a storyteller. Through SunExplains, I explain security in simple, relatable terms — connecting technology, trust, and everyday life.
Leave a Reply