Identity has become the new security perimeter. When applications live in the cloud, employees work from home and suppliers access internal systems, the corporate firewall ceases to be the boundary that protects the organisation. What truly protects it is the right answer to two questions: who are you? (authentication) and what are you allowed to do? (authorisation). Identity and access management, known by its acronym IAM (Identity and Access Management), is the discipline that answers both in a systematic, auditable and reproducible way.
This article walks through the technical components of modern IAM, the standard protocols that underpin it, the regulations applicable in Spain and the European Union, and the concrete steps to deploy robust authentication without getting in the user's way.
What IAM is and why the perimeter is no longer enough
IAM is the set of policies, processes and technologies that ensures the right people and services access the right resources, at the right time and for the right reasons. It comprises four core functions: authentication (verifying identity), authorisation (deciding what that identity can do), administration (creating, removing and modifying accounts throughout their lifecycle) and auditing (recording who accessed what and when).
The dominant security model in 2026 is Zero Trust, formalised by NIST in special publication SP 800-207. Its guiding principle is "never trust, always verify": no request is considered trustworthy simply because it originates from the internal network. Every access is evaluated continuously based on identity, device posture, location and context. IAM is the engine that makes Zero Trust operational, because every access decision starts from a verified identity.
Authentication: passwords, MFA and the road to passwordless
The password, on its own, is a weak factor. According to annual security breach reports, stolen or reused credentials remain the most common intrusion vector. Multi-factor authentication (MFA) mitigates this risk by requiring two or more factors from different categories: something you know (a password, a PIN), something you have (a phone, a physical key) and something you are (a fingerprint, a face).
Not all second factors offer the same protection. Sending codes by SMS is vulnerable to fraudulent SIM swapping and to interception of the SS7 network; the NIST SP 800-63B guidelines advise against SMS as a high-assurance factor. Time-based one-time password apps (TOTP, based on the RFC 6238 standard) are markedly more secure. The highest level currently available comes from FIDO2/WebAuthn security keys, which are phishing-resistant because the cryptographic credential is bound to the legitimate domain and never leaves the device.
The horizon is passwordless authentication through passkeys, access keys based on asymmetric cryptography that replace the password entirely. The user authenticates with their device's biometrics or PIN, and the device signs a cryptographic challenge. There is no shared secret to steal, so traditional phishing stops working.
SSO and federation: SAML, OAuth 2.0 and OpenID Connect
Single Sign-On (SSO) allows a user to authenticate once and then access multiple applications without re-entering credentials. This reduces password fatigue, lowers support tickets and centralises access control. Three protocols underpin modern SSO:
| Protocol | Main function | Format | Typical use case |
|---|---|---|---|
| SAML 2.0 | Enterprise authentication and SSO | XML | Corporate applications, B2B SSO |
| OAuth 2.0 | Delegated authorisation (resource access) | JSON/JWT tokens | APIs, third-party access to data |
| OpenID Connect | Authentication on top of OAuth 2.0 | JWT (ID Token) | Social login, web and mobile apps |
It is important not to confuse them: OAuth 2.0 is an authorisation framework, not an authentication one; it solves how an application obtains permission to access resources on the user's behalf. OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0 and issues a signed identity token (ID Token) that does prove who the user is. SAML remains the workhorse of classic enterprise SSO, especially in integrations with established identity providers.
Authorisation: from RBAC to ABAC and the principle of least privilege
Once identity has been verified, you have to decide what it can do. Role-based access control (RBAC) groups permissions into roles (for example, "accounting", "systems administrator") and assigns roles to users. It is simple to govern and sufficient for most organisations. Attribute-based access control (ABAC) is more granular: decisions depend on attributes of the user, the resource and the context (department, time, location, data sensitivity), and they are expressed as policies that can be evaluated in real time.
Above either model rules the principle of least privilege: each identity receives only the permissions strictly necessary for its function, and nothing more. Its operational complement is just-in-time access, which grants elevated privileges temporarily and revokes them automatically, reducing the attack surface of privileged accounts.
The identity lifecycle and provisioning
An identity is born when someone joins, changes when they move roles and must die the day they leave. Automated provisioning through the SCIM (System for Cross-domain Identity Management) standard synchronises creations, removals and modifications between the corporate directory and SaaS applications. The biggest risk here is late deprovisioning: ex-employee accounts that remain active weeks after departure. Mature identity governance runs periodic access reviews and disables orphaned accounts systematically.
Regulatory framework: GDPR, NIS2 and certification schemes
The General Data Protection Regulation (GDPR) requires appropriate technical measures to be applied to ensure the security of processing (Article 32), among which access control and traceability are central pieces. In Spain, the Spanish Data Protection Agency (AEPD) provides guidance on implementing these measures. The NIS2 Directive, transposed into the law of the Member States, strengthens cybersecurity obligations for essential and important sectors and expressly includes access control and multi-factor authentication among the required measures. At the management level, the ISO/IEC 27001 standard and its catalogue of ISO/IEC 27002 controls detail the requirements for identity management, authentication and access review within an information security management system.
Privileged Access Management (PAM)
Not all identities are equal. Privileged accounts—systems administrators, database administrators, domain administrators—concentrate disproportionate power and are the favourite target of any attacker: compromising one of them is usually equivalent to compromising the entire organisation. Privileged Access Management (PAM) is the specific discipline that protects these accounts through credential vaults that rotate passwords automatically, supervised and recorded sessions, and just-in-time privilege elevation that grants permissions during a limited window and revokes them when finished.
The principle that underpins PAM is that no one should have permanent administrative access "just in case". Every use of an elevated privilege leaves an auditable trail, is justified with a reason and expires on its own. Combined with MFA and centralised event logging, PAM closes one of the most exploited gaps in serious security incidents: administrative credentials that are forgotten, shared or never rotated.
Common mistakes that compromise an IAM deployment
- SMS-based MFA as the only safeguard: better than nothing, but vulnerable; prioritise TOTP or FIDO2.
- Service accounts with excessive permissions: unrotated credentials with administrator privileges are a priority target for attackers.
- Failing to revoke access on departure: a frequent source of incidents; automate deprovisioning.
- Allowing "temporary" MFA exceptions that become permanent.
- Not recording or reviewing authentication events, which makes it impossible to detect anomalous access.
Frequently asked questions
Are MFA and 2FA the same thing? Two-step verification (2FA) is a particular case of MFA with exactly two factors. MFA is the generic term for two or more factors.
Doesn't SSO increase risk by concentrating access in a single credential? SSO concentrates the authentication point, which is why it must be protected with robust MFA. In return, it eliminates the proliferation of weak and reused passwords, which is a greater risk in practice.
Do passkeys eliminate the need for MFA? A passkey combines, in a single gesture, possession (the device) and inherence or knowledge (biometrics or PIN), so it already constitutes strong, phishing-resistant authentication; it does not require an additional second factor.
Where do I start if I have no IAM? By enabling MFA on privileged and administrative accounts, inventorying existing identities and removing orphaned accounts. It is the highest-impact change at the lowest cost.
Conclusion
Identity security is not a product you buy once, but a continuous practice of verification. The organisation that adopts phishing-resistant MFA, centralises access with SSO over standard protocols, applies least privilege through RBAC or ABAC and automates the account lifecycle eliminates at a stroke the most exploited intrusion vectors: stolen credentials, orphaned accounts and forgotten privileges. The destination is a passwordless environment governed by Zero Trust, where every access is evaluated by its context and where stealing a password no longer makes sense because there are no passwords left to steal. At Summum Sistemas we design IAM architectures that advance towards that destination without sacrificing teams' productivity.