Identity and access
By the end of this module you will be able to:
- Classify authentication factors by category and explain why combining categories is stronger than repeating a single one
- Compare the security properties of SMS OTP, TOTP, and FIDO2 as second factors
- Distinguish between RBAC and ABAC and identify which is more appropriate in a given scenario
- Apply the principle of least privilege to a user access review scenario
Real-world incident · 15 July 2020
Attackers called Twitter's internal support line. Within hours they controlled Barack Obama's account.
On 15 July 2020, attackers compromised the Twitter accounts of Barack Obama, Joe Biden, Elon Musk, Bill Gates, Apple, Uber, and 124 other high-profile accounts. From those accounts, they broadcast a cryptocurrency scam that generated over $120,000 in Bitcoin in a matter of hours.
The attackers did not find a software vulnerability. They called Twitter's internal support line, impersonated IT colleagues, and persuaded at least two employees to provide access to an internal administrative tool called "Agent Tool." Using this tool, they changed the email addresses associated with target accounts, disabled two-factor authentication, and reset passwords. Every user-facing security control was bypassed by targeting insider access directly.
Three individuals were later charged. The youngest was 17 years old. The breach demonstrated that identity and access management is not merely a technical problem. Verified identity, access scoped to what is genuinely necessary, and processes that cannot be bypassed by social pressure are all required together.
The attackers bypassed every user-facing security control without exploiting a single software vulnerability. What does this reveal about where the real identity and access problem was?
With the learning outcomes established, this module begins by examining authentication factors: what they are and why combining them matters in depth.
6.1 Authentication factors: what they are and why combining them matters
Before a system grants access, it must verify the identity of the party requesting it. This process is authentication. The evidence provided during authentication falls into three categories, known as factors.
Something you know covers knowledge factors: passwords, PINs (Personal Identification Numbers), and security questions. These are the most widely used but also the most vulnerable, because knowledge can be stolen, guessed, or phished.
Something you have covers possession factors: a physical security key, a smartphone running an authenticator app, or a smart card. Possession factors are harder to steal remotely because the attacker needs physical access or malware on the device.
Something you are covers inherence factors: fingerprints, facial recognition, retina scans. Biometric factors are convenient and difficult to share deliberately, but they cannot be changed if compromised and may have false acceptance or rejection rates that create usability problems.
MFA (Multi-Factor Authentication) combines factors from at least two different categories. The key word is different categories: two passwords are not MFA. A password and a TOTP (Time-based One-Time Password) code from an authenticator app are MFA, because one is something you know and the other is something you have (the device generating the code).
“Authenticators shall be selected from the following authenticator types: Memorized Secrets, Look-Up Secrets, Out-Of-Band Devices, Single-Factor OTP Devices, Multi-Factor OTP Devices, Single-Factor Cryptographic Software, Single-Factor Cryptographic Devices, Multi-Factor Cryptographic Software, Multi-Factor Cryptographic Devices.”
NIST SP 800-63B-4 (July 2025), Digital Identity Guidelines: Authentication and Authenticator Management - Section 5, Authenticator and Verifier Requirements
NIST SP 800-63B-4 is the current US federal standard for digital identity and authentication. It defines authenticator assurance levels (AAL1, AAL2, AAL3) based on which factor types are combined. AAL2 (the minimum for most government services) requires at least two factors from different categories. Revision 4 adds emphasis on phishing-resistant authenticators (FIDO2/WebAuthn) and syncable authenticators. The standard is widely referenced by UK organisations alongside NCSC guidance.
With an understanding of authentication factors: what they are and why combining them matters in place, the discussion can now turn to comparing second factors: sms, totp, and fido2, which builds directly on these foundations.
6.2 Comparing second factors: SMS, TOTP, and FIDO2
Not all second factors provide the same level of protection. Understanding the differences helps justify why an organisation might mandate a specific MFA type.
SMS OTP (Short Message Service One-Time Password) sends a code to the user's registered phone number. It is better than a password alone, but it is vulnerable to SIM-swapping attacks (where an attacker convinces a mobile carrier to transfer a victim's number to a SIM card they control), SS7 (Signalling System 7) interception vulnerabilities in the telecommunications network, and phishing pages that relay the OTP in real time before it expires.
TOTP generates a time-based code in an authenticator app (such as Google Authenticator or Authy) using a shared secret and the current time. It is not sent over the telecommunications network, so SIM-swapping and SS7 attacks do not apply. However, a sophisticated real-time phishing attack can still relay the TOTP code before it expires.
FIDO2 / WebAuthn is a W3C (World Wide Web Consortium) standard that uses public-key cryptography. The user registers a security key (such as a YubiKey) or a platform authenticator (such as Windows Hello or Face ID). During authentication, the key signs a challenge that includes the website's domain. Because the domain is cryptographically bound to the challenge, FIDO2 is completely phishing-resistant: even if a user is on a fake website, the authenticator refuses to sign for an unregistered domain. FIDO2 is the highest-assurance MFA option available at scale.
Common misconception
“Any MFA is equally strong. SMS is fine for everything.”
SMS OTP is significantly weaker than TOTP or FIDO2. The FBI and CISA (Cybersecurity and Infrastructure Security Agency) both issued guidance in 2021 recommending organisations move away from SMS MFA where possible, following multiple high-profile SIM-swap attacks against cryptocurrency exchanges and telecom staff. The Twitter breach used social engineering to bypass MFA entirely, which underscores that process controls around administrative tool access must accompany technical MFA deployment.
Common misconception
“Once access rights are assigned during onboarding, they do not need to change unless the employee leaves.”
Access creep is one of the most common and dangerous identity failures in organisations. Employees accumulate permissions as they change roles, take on temporary project assignments, or cover colleagues' duties, but permissions are rarely revoked when the original justification expires. A 2022 Verizon Data Breach Investigations Report found that 35% of breaches involved misuse of legitimate credentials, frequently because former role access was never revoked. Quarterly access reviews for privileged accounts and annual reviews for standard accounts are the primary control. The process is simple: ask each manager to confirm which of their team's permissions are still required and remove those that cannot be justified.
With an understanding of comparing second factors: sms, totp, and fido2 in place, the discussion can now turn to access control: rbac, abac, and least privilege, which builds directly on these foundations.
6.3 Access control: RBAC, ABAC, and least privilege
Authentication confirms who a user is. Authorisation determines what that user is allowed to do. Two primary access control models define how authorisation rules are structured.
RBAC (Role-Based Access Control) assigns permissions to roles rather than individual users. A user gains access by being assigned a role. A hospital might define roles such as Nurse, Doctor, Administrator, and Finance. Each role has a defined set of permissions. When a new employee joins, they receive the appropriate role rather than having permissions manually configured. RBAC is operationally straightforward and scales well for large organisations with predictable job functions.
ABAC (Attribute-Based Access Control) makes access decisions based on attributes: the user's department, the data's classification label, the time of day, and the user's location. A policy might state: "Allow access to patient records only if user.department = Clinical AND record.sensitivity = OFFICIAL AND access.time is between 07:00 and 22:00 AND access.location = Hospital." ABAC provides fine-grained control for complex environments but requires careful policy design and is harder to audit.
“The principle of least privilege states that each subject (user, process, or system) should be given only the minimum access rights needed to perform its authorized functions.”
NIST SP 800-12 Rev.1, An Introduction to Information Security - Section 3.4, Least Privilege
Least privilege is the foundational principle underlying both RBAC and ABAC. In the Twitter breach, the Agent Tool had access to account management functions for all 330 million Twitter accounts. A least-privilege design would have scoped each support role's access to the accounts relevant to their responsibilities, limiting the blast radius of any single compromised account.
In practice, access creep is one of the most common identity failures in organisations. Users accumulate permissions as they change roles over time, but permissions are rarely revoked when they are no longer needed. Regular access reviews, typically quarterly for privileged accounts and annually for standard accounts, are the primary control. The process is simple: ask each manager to confirm which permissions each of their direct reports actually needs. Remove those that cannot be justified.
With an understanding of access control: rbac, abac, and least privilege in place, the discussion can now turn to single sign-on and session management, which builds directly on these foundations.
6.4 Single sign-on and session management
SSO (Single Sign-On) allows a user to authenticate once and access multiple systems without re-entering credentials. Common SSO protocols include SAML 2.0 (Security Assertion Markup Language) and OpenID Connect, which builds on OAuth 2.0. SSO improves usability by reducing password fatigue and improves security by centralising authentication, meaning MFA enforcement can be applied at the identity provider rather than inconsistently across individual applications.
The security trade-off: centralising authentication creates a single high-value target. If the identity provider is compromised, all connected applications are at risk. This is why identity providers (such as Azure AD, Okta, or Google Workspace) require the strongest available MFA and receive enhanced monitoring attention.
The Twitter breach targeted an administrative tool rather than an identity provider. Internal administrative tools often bypass standard SSO and MFA flows, operate with broad permissions, and have weaker audit logging than customer-facing systems. In access control design, internal tools deserve the same scrutiny as public-facing ones.
A user authenticates with a password and then receives an SMS code to enter. Their phone number was SIM-swapped by an attacker last week. Which statement about this MFA setup is most accurate?
A hospital IT manager is auditing access rights. A nurse who moved to administrative work six months ago still has clinical system access she used in her previous role. Which access control principle was most clearly not followed?
In the Twitter 2020 breach, attackers persuaded support employees to grant them access to the Agent Tool, which had broad account management capabilities. Which access control design change would most directly have limited the damage?
Key takeaways
- Authentication factors fall into three categories: something you know (password), something you have (security key, phone), and something you are (biometric). MFA combines factors from different categories.
- SMS OTP is weaker than TOTP and significantly weaker than FIDO2. FIDO2 is phishing-resistant because authentication is cryptographically bound to the specific website domain.
- RBAC assigns permissions to roles, which users inherit. ABAC applies policy rules using multiple attributes. Both are governed by the principle of least privilege.
- Access creep is the most common identity failure. Regular access reviews catch and remove permissions that users no longer need.
- SSO centralises authentication and enables consistent MFA enforcement. The identity provider becomes a high-value target requiring enhanced controls.
You now understand how identity is verified and access is controlled. But the Twitter breach showed that even strong technical controls can be bypassed when an attacker targets the human rather than the system. Why do people comply with attackers, and what actually reduces phishing click rates? Module 7 covers human factors, social engineering taxonomy, and evidence-based awareness training.
Standards and sources cited in this module
Section 5, Authenticator Requirements; Section 4, Authenticator Assurance Levels
Defines authenticator types, assurance levels (AAL1-3), and requirements for MFA. Revision 4 adds phishing-resistant authenticator emphasis. Cited in Section 6.1 for the factor categories framework.
W3C Web Authentication (WebAuthn) Level 2 Specification (2021)
Section 6, Authenticator Data
Defines the FIDO2 WebAuthn standard and cryptographic binding to the relying party origin. Referenced in Section 6.2 for phishing resistance.
NIST SP 800-207, Zero Trust Architecture
Section 2.1, Zero Trust Tenets
Establishes least privilege and continuous verification as core zero trust principles. Referenced in Section 6.3.
US Department of Justice, Twitter Breach Charges (July 2020)
Criminal complaint documentation
Primary source for the Twitter 2020 breach details: Agent Tool access, social engineering of support staff, and scope of access. Used as the opening case study.
Module 6 of 25 · Cybersecurity Foundations