Access Control

Multi-Factor Authentication on Jump Servers: Doing It Without Exceptions

A jump server without enforced MFA is a password away from being an attacker’s single point of access to everything.

Multi-Factor Authentication on Jump Servers: Doing It Without Exceptions — diagram

Why the gateway is the right place

Deploying MFA across hundreds of servers individually is a multi-year programme that usually stalls. Deploying it at the one host every administrative session must cross is a single change that covers all of them — provided the targets genuinely refuse connections from anywhere else.

That is the leverage of the chokepoint: one control, applied once, inherited by everything behind it.

Choosing factors

FactorPhishing resistantWorks offlineNotes
FIDO2 / WebAuthnYesYesStrongest practical option; origin-bound so it cannot be relayed
PIV / CAC smart cardYesYesStandard in government and defense; needs PKI already in place
TOTP appNoYesGood baseline; a convincing proxy page can capture and replay a code
Push notificationNoNoVulnerable to fatigue attacks; requires number matching to be safe
SMSNoNoSIM swap and SS7 interception; avoid for privileged access

For a gateway that fronts high-consequence systems, hardware-backed factors are worth the procurement effort. They also remove a dependency: a token validated locally keeps working when the internet does not, which matters during exactly the incidents you care about. See high availability.

The exception group problem

Nearly every stalled MFA rollout has the same shape. Enforcement is turned on, three cases genuinely cannot comply, an exception group is created for them, and eighteen months later that group has forty members and nobody remembers why most of them are in it.

An exception group with no expiry is a permanent bypass with a reassuring name. If exceptions are unavoidable, give every membership an end date enforced by the system, alert on additions, and review the list monthly — not annually.

Automation without a bypass

The legitimate objection is automation: pipelines and scheduled jobs cannot present a second factor. The answer is not to exempt them from MFA but to remove them from the interactive path entirely.

  • Give machine identities their own credentials, scoped to exactly the target and action required
  • Bind them to source address, so a stolen key is useless from elsewhere
  • Prefer short-lived, issued credentials over long-lived static keys
  • Never let a human borrow a service credential to skip the prompt — that is the bypass, wearing a costume

Enrolment and recovery are the attack surface

Strong authentication is only as strong as the process for issuing and replacing it. If a help desk agent can reset a factor after a phone call, the factor is worth what that call costs an attacker.

  • Verify identity out of band before enrolment, ideally in person for privileged roles
  • Require two factors to register a new one where possible
  • Log every enrolment and reset as a privileged event, reviewed like any other
  • Issue backup tokens rather than printable recovery codes that end up in a drawer

Do not stop at the front door

MFA proves who opened the session. It says nothing about what happens during it. Pair it with session recording, expiring authorisation, and approval on the targets that warrant it — the gateway’s value comes from the combination, not from any single control.

Related field notes

← OlderJump Servers for OT and SCADA: Securing the IT/OT BoundaryNewer →Jump Server Logging and SIEM Integration: What to Forward and What to Alert On

Next Step

Want this discipline over your own network?

We will walk your current access paths and show exactly where the gateway sits.