AC-17(10): Authenticate Remote Commands

AC-17(10) requires you to authenticate remote commands before a system executes them, using defined technical mechanisms for the types of remote commands you allow. Operationalize it by inventorying remote command paths (SSH, APIs, orchestration tools), enforcing strong authentication on command issuance, and retaining logs that prove who issued each command and how it was authenticated. ¹

Key takeaways:

• Treat “remote commands” as a high-risk control plane and require authenticated command submission end to end. ¹
• Standardize remote administration through approved tooling (bastions, management planes, signed APIs) so authentication is consistent and auditable. ²
• Your audit pass/fail hinges on evidence: configuration, access paths, and logs tying each remote command to an authenticated identity. ¹

The ac-17(10): authenticate remote commands requirement is a narrow enhancement with a broad blast radius. If an attacker, a compromised third party, or a misconfigured automation pipeline can send commands to production systems without strong authentication, they can change configurations, create accounts, disable controls, or exfiltrate data without needing interactive access. AC-17(10) exists to force a clean, provable chain of accountability for command execution over remote access channels. ²

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing AC-17(10) is to stop treating “remote access” as a single control. Remote command execution happens through multiple planes: human admin sessions (SSH/RDP), remote management tooling (systems management agents), CI/CD and infrastructure-as-code, and application-to-application APIs that trigger privileged actions. Your job is to define what “remote command” means in your environment, mandate the authentication method for each command path, and collect repeatable evidence that the mandate is enforced. ¹

This page gives requirement-level implementation guidance you can assign to control owners, turn into tickets, and defend in an assessment.

Regulatory text

NIST SP 800-53 Rev. 5 AC-17(10) excerpt: “Implement {{ insert: param, ac-17.10_odp.01 }} to authenticate {{ insert: param, ac-17.10_odp.02 }}.” ¹

Operator meaning (what you must do):

• Define the organization-determined parameters (ODPs) for AC-17(10):
  1. the mechanisms you will implement, and
  2. the types/classes of remote commands that must be authenticated. ¹
• Enforce those mechanisms so remote commands cannot be executed unless they are tied to an authenticated identity (human or service), and you can prove it with system evidence. ²

Plain-English interpretation

Remote commands are instructions sent to a system from another system or user over a network path. AC-17(10) requires you to ensure the system only accepts those commands when the sender is authenticated according to your defined standard. ¹

In practice, assessors look for two things:

1. Control-plane standardization: You route remote admin and automation through approved channels that enforce authentication consistently.
2. Attribution: Logs show which identity issued the command, from where, using what authentication, and what happened. ²

Who it applies to (entity and operational context)

Entity types commonly in scope:

• Federal information systems and contractor systems handling federal data, including environments assessed against NIST SP 800-53 Rev. 5. ²

Operational contexts that trigger AC-17(10) relevance:

• Interactive administration over remote access (SSH, RDP, VDI admin jump hosts).
• Remote execution via management/orchestration tools (endpoint management agents, configuration management, container orchestration).
• CI/CD jobs or infrastructure-as-code that execute privileged commands remotely.
• Service-to-service APIs that perform administrative actions (create users, rotate keys, change firewall rules).
  If a pathway can change system state remotely, treat it as a candidate “remote command” and decide whether it falls under your ODP scope. ²

What you actually need to do (step-by-step)

Step 1: Set your AC-17(10) parameters (ODPs) in writing

Create an AC-17(10) control statement with two explicit lists. ¹

A. “Remote commands” you will cover Use a short, defensible scope such as:

• Privileged interactive commands on servers/network devices.
• Remote execution jobs in orchestration/config management.
• Administrative API calls that change access, configuration, or security posture.

B. “Mechanisms” you will use to authenticate Pick mechanisms your engineering teams can enforce and prove, for example:

• Centralized identity (SSO/IdP) with MFA for human admins.
• Short-lived certificates or SSH certs tied to enterprise identity.
• Signed requests/tokens for APIs (mutual TLS, OAuth client credentials) tied to service identities.
• Privileged access management (PAM) brokering sessions and recording.
  Your mechanisms can vary by channel, but document the mapping. ²

Deliverable: an AC-17(10) implementation standard that a system owner can follow without interpretation.

Step 2: Inventory remote command pathways and name the owners

Build a table that lists every sanctioned way commands are executed remotely for in-scope systems. Keep it simple and operational:

Pathway	Example tools	Human or service	Auth mechanism required	Logging source	Control owner

This inventory becomes your scoping backbone during audits and incident response. ²

Step 3: Enforce “only approved paths” for remote command execution

Most AC-17(10) failures come from side doors: local accounts, unmanaged SSH keys, shared admin passwords, long-lived API keys, or direct-to-host access bypassing the bastion.

Minimum enforcement patterns:

• Network restriction: Only bastions/management planes can reach admin ports on production.
• Identity restriction: Disable shared admin accounts; require named accounts or named service principals.
• Key/token hygiene: Prohibit unmanaged long-lived credentials for remote administration.
  Tie these to your remote access control family decisions under AC-17 to keep the story consistent. ²

Step 4: Make authentication provable (not just “configured”)

For each pathway, define what “proof” looks like:

• For interactive access: evidence that the user authenticated through your IdP/PAM and the session maps to an individual.
• For automation: evidence that the job runs as a specific service identity and uses approved token/cert mechanisms.
• For APIs: evidence that administrative endpoints require authenticated requests and reject anonymous/weakly authenticated calls. ¹

Step 5: Centralize logs and build a command-attribution trail

You need logs that connect:

1. identity → 2) authentication event → 3) command/request → 4) target system action.

Concrete logging targets:

• Bastion/PAM session logs (who, when, where, what target).
• System logs indicating remote login/command execution (where feasible).
• API gateway logs for privileged endpoints (client identity, token subject, request metadata).
• CI/CD logs for privileged deploy steps (runner identity, service account used). ²

Step 6: Test the control with negative cases

Run tests you can show an auditor:

• Attempt remote command execution without authentication and confirm rejection.
• Attempt with a non-approved identity and confirm rejection.
• Attempt with approved identity and confirm acceptance with logs generated. ²

Step 7: Operationalize governance: exceptions, reviews, and drift control

Define:

• Exception process for legacy systems (time-bound, compensating controls, owner sign-off).
• Periodic review of remote admin paths and service identities (especially CI/CD and APIs).
• Monitoring for new exposed admin ports, new access keys, or new automation roles. ²

Required evidence and artifacts to retain

Keep evidence in an assessor-ready binder format ¹. ²

Design artifacts

• AC-17(10) control statement with ODP definitions (remote command classes + mechanisms). ¹
• Remote command pathways inventory with owners and enforced mechanisms.
• Architecture diagrams showing bastions, management planes, CI/CD runners, API gateways.

Implementation evidence

• Configuration screenshots/exports:
  • IdP/PAM enforcement settings for admin access.
  • SSH/PAM/bastion configuration that prevents direct access.
  • API gateway or service config requiring authenticated requests for admin endpoints.
• Sample log extracts demonstrating attribution from authentication to execution (redact sensitive data).
• Test records for rejection/acceptance cases.

Operational evidence

• Access review records for admin groups and service accounts tied to remote execution.
• Exception register and approvals for any non-standard remote command paths.
• Monitoring/alerting rules tied to remote admin and privileged API activity.

Common exam/audit questions and hangups

Expect these, and prepare “show me” answers:

1. “Define ‘remote command’ for your environment.”
   Have your ODP scope statement and pathway inventory ready. ¹

2. “How do you prevent bypass of the approved remote admin path?”
   Be ready to show network controls and account restrictions, not just policy text. ²

3. “How do you authenticate automation?”
   Assessors will ask about CI/CD runners, service accounts, and key management. Map each pipeline to a service identity and mechanism. ²

4. “Show evidence for a specific production change.”
   Pick an example: a firewall rule change, privileged deployment, or configuration update. Produce the authentication event and the resulting action logs.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating MFA on VPN as sufficient.
  VPN user auth does not automatically authenticate each remote command, especially for automation or lateral movement. Control the command pathways themselves. ²

• Mistake: Shared admin credentials for remote tools.
  Shared identities break attribution. Require unique identities for humans and distinct service principals for automation. ²

• Mistake: Long-lived SSH keys/API keys with no ownership.
  Tie credentials to identity governance. Rotate, revoke, and log usage through managed systems. ²

• Mistake: Logging exists but cannot answer “who ran what.”
  Log volume is not evidence. Validate that logs include identity fields and that you can retrieve them for a specific event. ²

• Mistake: Unowned control.
  AC-17(10) crosses IAM, infrastructure, and app teams. Assign a control owner and name evidence owners per pathway. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AC-17(10). ¹

Risk still shows up directly in assessments and incident handling:

• Unauthenticated or weakly authenticated remote commands are a direct route to privilege escalation and unauthorized change.
• Poor attribution slows containment and complicates reporting because you cannot prove which identity executed an action. ²

A practical 30/60/90-day execution plan

Use phases so you can move without waiting for perfect architecture. ²

First 30 days (stabilize scope and stop obvious gaps)

• Assign control owner and technical owners per environment (on-prem, cloud, endpoints, CI/CD, APIs). ¹
• Publish AC-17(10) ODPs: remote command classes in scope and approved authentication mechanisms. ¹
• Build the remote command pathways inventory for in-scope systems.
• Identify high-risk bypass paths (direct SSH/RDP to prod, shared keys, unmanaged admin APIs) and open remediation tickets.
• Define evidence pack format and start collecting baseline configs and sample logs.

Days 31–60 (enforce and prove)

• Implement technical enforcement for approved pathways (bastion/PAM, API gateway auth, CI/CD service identity controls). ²
• Turn on centralized logging and confirm identity fields are captured.
• Execute negative/positive tests for each pathway and store results.
• Stand up an exception process for systems that cannot meet the standard yet, with compensating controls and dates.

Days 61–90 (operationalize and make it repeatable)

• Run an internal assessment using the audit questions above; fix evidence gaps.
• Add monitoring for drift: new admin ports, new service accounts, new privileged API endpoints.
• Formalize recurring reviews (admin group membership, service identity inventory, exception register).
• If you use Daydream to manage control mapping and evidence collection, set AC-17(10) to a named owner, attach the pathway inventory, and schedule recurring evidence tasks so the control stays audit-ready. ¹

Frequently Asked Questions

Does AC-17(10) only apply to human admins using SSH/RDP?

No. Any remote mechanism that can cause command execution or administrative action can fall in scope, including CI/CD jobs and privileged APIs, based on your defined parameters. ¹

If users authenticate to a VPN with MFA, is that enough?

Usually not as standalone evidence for AC-17(10). You still need authentication on the command path (bastion/PAM, SSH certs, API auth) and logs tying actions to identities. ²

How do we “authenticate remote commands” for automation and service accounts?

Require automation to run under a dedicated service identity with controlled credentials (tokens/certs/managed identity) and log the identity used for each remote action. Document that mapping in your pathway inventory. ²

What evidence do auditors ask for first?

They typically ask for your defined scope/mechanisms (ODPs), then a demonstration of enforced access paths, and finally logs for a real change showing identity-to-action attribution. ¹

We have legacy systems that cannot integrate with SSO. Can we still comply?

Use a time-bound exception with compensating controls such as PAM brokering, network isolation, and enhanced monitoring, and document the plan to migrate to the standard mechanism. ²

How do we keep this from becoming a one-time audit exercise?

Assign owners, keep the pathway inventory current, automate evidence collection, and review exceptions and privileged identities on a recurring cadence aligned to your governance program. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5