Security & Identity

Duo MFA

A second factor on the paths that matter - and a deliberate answer to the question that decides what MFA is actually worth: what happens when the MFA service itself is unreachable.

What it is & why I use it

Duo provides the multi-factor layer on privileged access in AutomationLab. Where a password alone is not enough - administrative and remote access paths - a second factor (a push, a one-time code) has to be satisfied before access is granted. It is the "something you have" on top of "something you know."

I use it because credentials leak; that is a when, not an if. MFA is the control that makes a stolen password insufficient on its own, so the paths most worth protecting do not fall to a single reused or phished secret.

How I use it in the lab

  • On privileged paths, not everything. The second factor guards the high-value access - administrative and remote entry - where the cost of a compromise is highest.
  • Layered with the edge and identity. MFA sits alongside the zero-trust edge and the identity provider, so protected access requires both a proven identity and a second factor, not one or the other.
  • A deliberate unreachable-service policy. The behavior when the MFA service cannot be reached is a decision I made on purpose, not a default I inherited (see the gotcha).
  • Phishing-resistant factors preferred. Where possible the stronger factors are favored over a simple approve-the-push, because a push a user can reflexively accept is a weaker link.

Architecture

Diagram coming Privileged access: identity check + second factor -> access, with an explicit policy for when the MFA service is unreachable. Scrubbed of hostnames, addresses, and any enrollment detail.

In action

Screenshot coming A privileged login prompting for the second factor before granting access. Captured per the publishing checklist - usernames, hostnames, and addresses redacted.

Lessons learned & gotchas

Gotcha - "fail open vs fail closed" is the whole security decision The setting that quietly decides how much your MFA is worth: what the access path does when the MFA service cannot be reached. Fail open (allow on MFA failure) keeps you from being locked out during an outage - but it means an attacker who can make MFA unreachable has just removed your second factor entirely, turning a strong control into a soft one exactly when it matters. Fail closed (deny on MFA failure) keeps the control honest under attack - but an MFA outage now locks out legitimate admins too, so it demands a tested break-glass path that does not itself depend on the thing that is down. There is no free answer; the mistake is not choosing deliberately and discovering your default during an incident.
  • Have a break-glass path, and test it. Fail-closed only works if there is a pre-planned, audited way in when MFA is down - one that does not route through the failed service. An untested break-glass is just a different outage.
  • A push you can reflexively approve is a weak factor. Prompt-bombing preys on fatigue - hammer someone with pushes until they tap approve. Number-matching and phishing-resistant factors blunt it; a bare approve/deny push does not.
  • MFA protects the path, not the secret behind it. It stops a stolen password from being enough - it does nothing for a credential that is used by machines with no human to prompt. Those belong behind scoped secrets and service identity, not MFA.

Impact

2FA
on privileged access
Chosen
fail-mode, not default
Break-glass
planned and tested

Duo makes a leaked password insufficient on the paths that matter most. The lasting lesson is that MFA's real strength is set by its failure behavior, not its happy path: decide fail-open versus fail-closed on purpose, build the break-glass the closed choice demands, and prefer factors that a tired human cannot be tricked into approving.

Code & further reading

Any published access-policy notes are scrubbed of hostnames, addresses, usernames, and enrollment detail before they go public.