Identity & Access Management: MFA, SSO, Federation, and the Principle That Ties Them Together

Attackers stopped breaking in years ago. They log in. Stolen and abused credentials are the single most common way into an organization, which is why identity and access management has quietly become the center of security architecture. Security+ SY0-701 gives it objective 4.6, and the questions are unforgiving about vocabulary: authentication vs. authorization, SAML vs. OAuth, federation vs. SSO. Here's the whole model, sorted.

Three questions, in order

Every access decision answers three questions in sequence, and mixing them up is the most common way to lose marks on this objective:

The factors, and why "multi" matters

Authentication evidence comes in categories, and MFA means combining different ones. Two passwords are not MFA; a password plus a code is.

Two attributes cut across these: something you do (behavioral patterns like typing rhythm) and, more importantly for the exam, the distinction between an authentication factor and an attribute: location and behavior are typically used as risk signals feeding adaptive identity, not as standalone proof.

SSO and federation: one login, many services

Single sign-on is the user experience; federation is the trust relationship that makes it possible across organizational boundaries. The security argument for both is counterintuitive but strong: fewer passwords means fewer places to phish, one place to enforce MFA, and one switch to flip at termination.

The pieces are always the same. An identity provider (IdP) authenticates the user and vouches for them; a service provider (SP) trusts that vouching instead of running its own login.

Three protocol names show up constantly, and the exam wants the distinction crisp:

The single most tested confusion: OAuth authorizes, OIDC authenticates. If a stem describes granting an app limited access to your data, it's OAuth; if it describes proving who you are to sign in, it's OIDC.

Federation also concentrates risk in a way worth stating plainly. Centralizing authentication is a security gain (one place to enforce MFA, one place to revoke) but it makes the IdP a single point of catastrophic failure. An attacker who compromises the identity provider, or who can forge the tokens it signs, inherits every application that trusts it, and does so as a legitimate user with valid sessions. That's why IdP admin accounts get the strongest available controls, why token-signing keys belong in hardware, and why anomalous sign-in monitoring is a required control rather than a nice-to-have.

What credential attacks actually look like

The vocabulary lands better once you've walked an attack through it. Security+ names these families, and they chain naturally:

• Credential stuffing: reusing leaked pairs elsewhere. Cheap, automated, and effective precisely because people reuse passwords.
• Password spraying: one common password against thousands of accounts, deliberately slow enough to evade lockout.
• Brute force and offline cracking: feasible against stolen hashes, which is why salted, slow hashing matters.
• Push fatigue / MFA bombing: repeated prompts until someone approves to make it stop.
• Session hijacking / token theft, the post-MFA bypass: steal the session and the login is irrelevant.

Chain them and you get the modern intrusion: a password sprayed from a breach corpus succeeds on a service account, MFA prompts are approved out of annoyance, and a stolen session token keeps access alive after the password is finally rotated. Notice which controls actually break that chain: phishing-resistant factors stop step one and two, and short session lifetimes plus token binding blunt step three. Password complexity rules stop none of it, which is exactly why current guidance favors length, screening against known-breached passwords, and MFA over forced periodic rotation.

Access control models: how permissions get decided

Once identity is established, a model decides what it unlocks. Know all five by their deciding factor:

• RBAC: permissions follow job roles. The workhorse of enterprise IT, and the easiest to audit.
• ABAC: decisions evaluate attributes and context (department + device + time + sensitivity). Most flexible, most complex.
• DAC: the owner of a file decides who may read it. Flexible; drifts badly at scale.
• MAC: labels and clearances enforced by the system, not the owner. Government and military contexts.
• Rule-based: access governed by system-wide rules (time-of-day windows, ACLs on a firewall), independent of identity.

Two principles govern all of them. Least privilege grants the minimum needed for the job; separation of duties ensures no single person can complete a sensitive process alone. The failure mode the exam loves is privilege creep: someone moves teams four times in six years and keeps every permission they ever had. Periodic access reviews and recertification are the answer.

The lifecycle, and the privileged edge case

Identity is not a one-time event. It's a lifecycle: provisioning (create the account, grant baseline access), changes (adjust as the role changes, and remove what's no longer needed), and deprovisioning (disable promptly at termination). Automating deprovisioning matters more than it sounds: orphaned accounts belonging to people who left are among the quietest paths into a network, because nobody is watching an account nobody uses.

Two account types deserve their own handling. Service accounts authenticate machines to machines. They rarely rotate, often hold broad rights, and can't answer an MFA prompt, which makes them a favorite target; the modern answer is workload identity and short-lived credentials rather than a permanent password in a config file. Guest and third-party accounts extend your trust boundary to another organization, so they need expiry dates by default, not indefinite access granted during one project in 2023.

Administrative accounts get their own discipline, because the blast radius is categorically different. PAM adds four things worth naming individually: credential vaulting, so admins check out a password they never actually know; just-in-time elevation, so rights exist for a window rather than permanently; ephemeral accounts, created for a task and destroyed after; and session recording, so privileged activity leaves reviewable evidence.

The underlying idea is the one the exam rewards: standing privilege is the risk. An admin account that holds domain rights 24/7 is a target every hour of every day; one that holds them for a 30-minute approved window is a target for 30 minutes and leaves an audit trail when it does. Pair that with separate admin identities (never administering from the account you read email with) and the most valuable credentials in your environment stop being permanently available to whoever phishes their owner.

IAM sits in Security+ Domain 4: Security Operations, 28% of the exam and the largest domain on the test. It also underpins Zero Trust, where identity replaces the network as the perimeter, and leans on the certificates and key material that make signed assertions trustworthy. Work all nine objectives with our Security+ Domain 4 study guide.

#SecurityPlus #SY0701 #IAM #MFA #SSO #Federation #OAuth #OIDC #SAML #ZeroTrust #CompTIA #CyberSecurity