Helpful first: Assets and the CIA triad: what we protect and how it fails
Key points
- Identity, authentication, authorization, and recovery are four jobs inside one login.
- Evaluate authentication assurance across Something You Know, Something You Have, and Something You Are (NIST SP 800-63)
- Explain why account recovery is an alternate authentication path that determines the true security floor of a system
One sign-in button, four separate architectural jobs
When Propulsion Lead Priya Nair signs in to the Meridian Space & Robotics (chronos.orbital) mission console, she sees a single login screen. Behind the scenes, however, Principal Security Architect Vera Vance audits that flow as four independent subsystems: Identity, Authentication, Authorization, and Recovery.
Whenever an engineering team blurs those four jobs, predictable vulnerabilities appear: a valid login session is treated as blanket admin permission (confusing authentication with authorization), or a hardware FIDO2 key requirement is bypassed by a two-minute help-desk phone reset (building a strong front door next to an unlatched recovery window).
One sign-in button, four separate architectural jobs
One sign-in button
Four separate architectural jobs
Identity
Authentication
Authorization
Recovery
Blanket admin permission
A valid login session is treated as blanket admin permission (confusing authentication with authorization).
Two-minute help-desk phone reset
A hardware FIDO2 key requirement is bypassed by a two-minute help-desk phone reset.
Tracing the four gates of access control
Let’s trace Priya’s request across the four gates shown in the diagram. First, Identity (Identification) is the unique, non-reused account record in Meridian’s directory (priya.nair@chronos.orbital or workload SPIFFE ID spiffe://chronos.orbital/ns/flight/sa/burn-planner) that ties actions to an accountable subject.
Second, Authentication (AuthN) tests whether the caller actually controls the cryptographic or behavioral proof bound to that identity. Third, Authorization (AuthZ) evaluates policy on every API request: given that this caller is authenticated as Priya, does she have permission to approve a thruster burn on satellite CHRONOS-4 right now? Fourth, Recovery is the out-of-band workflow used when Priya loses her yubikey or replaces her laptop.
| Stage | Core Question | Strong Engineering Pattern | Classic Failure Mode |
|---|---|---|---|
| Identity (Identification) | Who do you claim to be? | Unique human or service principal IDs; lifecycle tied to HR/workload registry | Shared admin accounts that destroy non-repudiation and audit trails |
| Authentication (AuthN) | Can you prove that claim right now? | Phishing-resistant FIDO2/WebAuthn (origin-bound asymmetric cryptography) | Password reuse, SMS OTP interception, or real-time AitM proxy phishing |
| Authorization (AuthZ) | What are you permitted to do on this specific resource? | Deny-by-default server-side policy check on every request (RBAC/ABAC) | Checking "is logged in" without verifying object ownership or role scope |
| Recovery | How do you regain access when primary authenticators are lost? | Pre-registered backup FIDO2 key or multi-party identity proofing with delay | Help-desk social engineering or unverified SMS reset overriding hardware MFA |
Authentication factors and phishing resistance (NIST SP 800-63B)
Authentication factors fall into three classic categories: Something You Know (passwords, PINs), Something You Have (cryptographic hardware tokens, smart cards, authenticator devices), and Something You Are (biometric traits). True Multi-Factor Authentication (MFA) requires combining at least two different categories; asking for a password plus a mother’s maiden name is merely two instances of Something You Know.
Not all MFA is equal against modern attackers. When an adversary lures an engineer to a reverse-proxy phishing page (login.chronos-orbital.net), the engineer types their password and their 6-digit TOTP code. The attacker’s proxy relays both to the real Identity Provider in real time. With push, the proxy submits the password, the engineer taps "Approve" on a push notification, and the Identity Provider gives the session to the proxy. FIDO2/WebAuthn defeats this completely because the browser binds the cryptographic challenge to the exact origin domain, and the key holds a credential only for chronos.orbital. When the browser bar says login.chronos-orbital.net, the hardware key signs nothing, so no signature exists for the proxy to relay.
Recovery sets the true assurance floor
In NIST SP 800-63, an authentication system is only as strong as its weakest recovery path. If Meridian mandates Authenticator Assurance Level 3 (AAL3) hardware keys for production access, but allows an employee to call the IT help desk, read off their employee ID number, and receive a temporary password + MFA bypass link, then the effective assurance of the entire system drops to knowledge-based verification. Recovery must require assurance equivalent to the primary credential, such as a secondary pre-enrolled hardware key stored in a safe or in-person supervisor + video identity verification.
CHECK YOUR JUDGMENT
Meridian Space & Robotics (chronos.orbital) rolls out mandatory FIDO2/WebAuthn hardware security keys for all production engineers. Two weeks later, an attacker calls the IT service desk pretending to be flight engineer Dax Mercer, claims his hardware key was damaged while traveling, answers two profile questions from LinkedIn, and convinces the agent to issue a temporary SMS bypass code. Which architectural principle was violated?
NEXT FIELD LESSON