Skip to content
ControlVerdict
MA.L2-3.7.5addresses
MA.L2-3.7.5Nonlocal Maintenance
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
  • [a]

    multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
  • [b]

    nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.

View full control

Vendor remote sessions: MFA to get in, watched throughout, torn down at hang-up

ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
Community is just starting — add yours. No verdicts yet.

Implementation

AO coverage. Addresses both Nonlocal Maintenance objectives: multifactor authentication to establish sessions over external network connections, and termination of those sessions when the work is complete.

One front door. All nonlocal maintenance comes through a single brokered remote access platform. There are no vendor-specific tunnels, no persistent site-to-site links for support, and no consumer remote desktop tools; the firewall denies the well-known ports for those outbound and inbound. Consolidating on one broker is what makes the rest of this enforceable.

Multifactor to establish. Vendor technicians authenticate to our identity provider with a named individual account — never a shared vendor login — and satisfy a multifactor requirement before the broker will create a session. Accounts are disabled by default and enabled only for an approved maintenance window, so a stolen vendor credential outside a window reaches nothing. The MFA requirement is enforced by conditional access policy on the broker application, not by the vendor's own promise to use MFA on their side.

Supervised while connected. An internal technician joins every session. The vendor sees only the system under maintenance; the broker constrains the session to that endpoint and file transfer is disabled unless explicitly enabled for the ticket. Sessions are recorded and retained.

Terminated when complete. The internal technician ends the session from our side at the conclusion of the work — the vendor closing their window is not the control. The broker also enforces an idle timeout and a maximum session duration, and the vendor account returns to disabled when the window closes. A nightly job reports any session that exceeded its window or any account left enabled, which caught two stragglers in the first month.

Maintenance. Monthly reconciliation of sessions against approved change tickets; quarterly review of vendor accounts for staleness; annual test that a vendor account cannot connect outside a window.

Accepted gap. During a Sev-1 outage the approval can be granted verbally by the IT director to avoid delay. The account enablement, session recording, and supervision still apply, and the ticket is created retroactively within 24 hours and reconciled in the monthly review.

What the evidence looks like

  • Remote access broker configuration showing MFA enforcement, idle timeout, and maximum duration
  • Conditional access policy scoping the broker application for vendor accounts
  • Firewall rules denying alternate remote support paths
  • Session recording sample with the internal supervisor present
  • Nightly exception report and the monthly session-to-ticket reconciliation

Environment

OSC supported by a managed service provider, with the ERP vendor and the firewall vendor connecting remotely for scheduled work roughly monthly.

Tools

Was this example useful?

Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.

Discussion(0)

No discussion on this example yet

Verdicts capture a conclusion. Use a thread when the interesting part is the argument.

Sign in to start a thread.