AC-17(2): Protection of Confidentiality and Integrity Using Encryption

AC-17(2) requires you to encrypt remote access sessions so their traffic stays confidential and cannot be altered in transit. To operationalize it quickly, you must inventory every remote access path, mandate approved encrypted protocols (and disable weak ones), enforce strong authentication and key/certificate management, and retain configuration and test evidence that proves encryption is always in effect. ¹

Key takeaways:

• Encrypt the session, not just the login page; the whole remote access channel must be protected. ¹
• Scope includes all remote sessions: admin access, user VPN, cloud consoles, third-party support paths, and remote management. ²
• Your fastest win is a “remote access encryption standard” plus hard technical enforcement and recurring evidence capture. ¹

The ac-17(2): protection of confidentiality and integrity using encryption requirement is an operational control, not a paperwork exercise. Assessors will expect you to show that remote access sessions are cryptographically protected end-to-end and that your organization has prevented common failure modes such as plaintext management protocols, downgrade paths, split-tunnel exceptions without compensating controls, and unmanaged third-party remote tools.

For a Compliance Officer, CCO, or GRC lead, the goal is to translate a short control statement into decisions that infrastructure and security teams can implement without ambiguity: which remote access methods are allowed, which cryptographic mechanisms are approved, how you validate that encryption cannot be bypassed, and what evidence you retain for audits. The fastest path is to treat “remote access” as a set of discrete session types (user, admin, third party, machine-to-machine) and apply a single enforceable baseline to each.

This page gives requirement-level implementation guidance: what to encrypt, where encryption must terminate, how to document the standard, and what artifacts to keep so you can pass a NIST SP 800-53 assessment with minimal back-and-forth. ³

Regulatory text

Requirement (AC-17(2)): “Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.” ¹

What the operator must do: For any connection that qualifies as remote access, you must ensure session traffic is encrypted and protected against tampering while traversing untrusted networks. Practically, this means you approve specific encrypted protocols/ciphers/versions, you force their use through configuration and network controls, and you verify enforcement through testing and logs. ¹

Plain-English interpretation

AC-17(2) is about protecting the entire remote session against eavesdropping and modification. If someone can sniff traffic on the path (public internet, partner network, home Wi‑Fi) or interfere with it (man-in-the-middle), encryption is your primary control to preserve confidentiality and integrity.

A passing implementation answers three questions cleanly:

1. Which remote sessions exist?
2. Which cryptographic mechanisms protect each session?
3. How do you prove the mechanisms are always active and current? ²

Who it applies to

Entity types

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational context (what “remote access sessions” means in practice) Include any interactive or programmatic session initiated from outside a controlled boundary into your environment, such as:

• User remote access (VPN, ZTNA, VDI).
• Administrative remote access (bastions/jump hosts, SSH/RDP to servers, remote cloud admin consoles).
• Third-party remote support (managed service providers, OEM support, incident response retainers).
• Remote management planes (hypervisor management, network device management, privileged access tooling).
• Remote API/admin sessions to SaaS or IaaS consoles when used to administer systems that store or process regulated data. ²

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

1) Define scope: enumerate every remote access path

Create a Remote Access Session Inventory that lists, per session type:

• Source (internet, partner network, contractor subnet).
• Destination (app, admin plane, production subnet).
• Protocol/tool (VPN client, SSH, RDP gateway, web console).
• Authentication method (SSO, MFA, keys/certs).
• Encryption mechanism (TLS, IPsec, SSH), including termination point.
  Output: a single spreadsheet or CMDB view that you can hand to an assessor.

2) Publish an enforceable “Remote Access Encryption Standard”

Write a short standard that engineering can implement without interpretation drift:

• Allowed protocols (example categories: TLS-based access, IPsec VPN, SSH; block plaintext management like Telnet/FTP).
• Minimum versions and configurations (state that weak/legacy protocol versions are prohibited; keep specifics in a technical baseline so updates don’t require policy rewrites).
• Certificate and key requirements (certificate authority, rotation expectations, storage requirements such as hardware-backed keys where feasible).
• Where encryption must terminate (for example: terminate at your controlled gateway, then re-encrypt to internal targets if traffic crosses untrusted segments).
• Exception process (time-bound, documented compensating controls, explicit risk acceptance).
  Tie the standard to AC-17(2) explicitly in your control narrative. ¹

3) Implement technical enforcement (not guidance)

Assessors look for technical controls that prevent bypass:

• Network enforcement: firewall rules to block plaintext or direct-to-host management from the internet; require access via a VPN/ZTNA gateway or bastion.
• Endpoint/server enforcement: disable insecure services; enforce “encrypt-only” settings (for example, SSH only; RDP only through a gateway with TLS).
• Centralized remote access points: consolidate pathways so you can apply consistent cryptographic settings and logging.
• Third-party tooling controls: restrict remote support tools to approved, managed options; require encryption at the session layer and enterprise logging.

4) Validate encryption and integrity protection with repeatable tests

Build a lightweight test plan:

• Configuration review: show relevant configuration screens or infrastructure-as-code that sets encryption parameters.
• Protocol verification: capture proof that weak protocols/versions are rejected and that approved encryption is negotiated.
• Path testing: test from an external network to confirm the only reachable remote access endpoints are the encrypted gateways.
  Document tests as an “AC-17(2) verification procedure” so results are repeatable across environments. ²

5) Operationalize: monitoring, change control, and drift management

Encryption can quietly regress due to upgrades, new endpoints, or third-party changes. Put in place:

• Configuration change control: remote access gateways and bastions require approvals and peer review for crypto-related changes.
• Continuous monitoring hooks: alerts for insecure protocol enablement, cert expiration, or newly exposed ports.
• Periodic evidence capture: scheduled exports of gateway configurations, certificate inventories, and firewall rules.

6) Map ownership and recurring evidence

Make AC-17(2) assessable:

• Control owner (usually IAM, network security, or platform security).
• Operators (network team, cloud platform team, endpoint team).
• Evidence cadence (aligned to your change velocity).
  This mapping step is explicitly called out as a recommended practice in your internal control guidance. ¹

Required evidence and artifacts to retain

Keep evidence that proves both design and operating effectiveness:

Design artifacts

• Remote Access Encryption Standard (approved and current).
• Remote Access Session Inventory with owners and encryption mechanisms.
• Architecture diagrams showing remote access entry points and termination.

Technical enforcement artifacts

• Gateway/bastion/VPN/ZTNA configuration exports (redact secrets).
• Firewall/security group rules showing allowed inbound management paths.
• Endpoint/server hardening settings that disable plaintext management protocols.

Operational artifacts

• Change tickets for crypto configuration changes.
• Certificate/key management records (issuance, rotation events, revocation where relevant).
• Verification test results (screenshots, command outputs, automated test logs).
• Exception register entries with approvals and compensating controls. ³

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me every way an admin can remotely access production, and where encryption is enforced.”
• “Do third parties use the same approved encrypted remote access path, or do they have separate tools?”
• “How do you prevent downgrade to weak crypto or plaintext protocols?”
• “Where do TLS sessions terminate, and what protects traffic after termination?”
• “What evidence proves this control operated throughout the period, not just today?” ²

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AC-17(2)	How to avoid it
Encrypting only the web login, but letting backend admin traffic run unencrypted	The session is still exposed after authentication	Require encrypted protocols end-to-end across the remote session path
Allowing “temporary” third-party remote tools	Creates unmanaged remote access channels	Approve a small set of managed tools and block the rest at egress/endpoint controls
Having multiple ad hoc entry points (open RDP/SSH on many hosts)	Too many places to misconfigure encryption	Funnel remote admin through a bastion or gateway with consistent crypto policy
No repeatable proof	Audits stall on “show me”	Standardize exports, test scripts, and a recurring evidence package

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not cite specific actions or outcomes.

Risk-wise, remote access is a high-frequency intrusion path. If you cannot prove encrypted session protections, you will struggle to defend the confidentiality and integrity of administrative actions and sensitive data traversing untrusted networks. From a GRC standpoint, the common control failure is not “no encryption exists,” but “encryption is inconsistent across remote paths and undocumented.” ²

A practical 30/60/90-day execution plan

Use phases to avoid made-up timelines while still giving you an execution track.

First 30 days (Immediate)

• Assign a single control owner and name technical operators for each remote access technology.
• Build the Remote Access Session Inventory and identify any plaintext or legacy protocols.
• Publish a one-page Remote Access Encryption Standard that engineering can enforce.
• Capture baseline evidence: current configs, diagrams, and a list of entry points. ¹

Next 60 days (Near-term)

• Consolidate remote admin access through controlled gateways (bastion/VPN/ZTNA).
• Disable plaintext management services and block associated ports at network boundaries.
• Implement certificate/key management workflows for remote access endpoints.
• Write and run the AC-17(2) verification procedure; store results as audit-ready evidence. ²

Next 90 days (Operationalize and scale)

• Add monitoring for crypto drift (protocol enablement, cert expiration, new exposed ports).
• Implement an exception register with required approvals and time bounds.
• Automate recurring evidence capture where possible (config exports, control attestation snapshots).
• Package everything into an “AC-17(2) evidence binder” so audits take hours, not weeks.

If you use Daydream for third-party risk and control operations, treat AC-17(2) as a mapped requirement with named owners, implementation procedures, and recurring evidence tasks. That structure reduces the most common failure mode: missing implementation evidence at assessment time. ¹

Frequently Asked Questions

Does AC-17(2) require a VPN for all remote access?

AC-17(2) requires encryption for remote access sessions, not a specific product category. A VPN, ZTNA, VDI, or another approach can satisfy the requirement if it cryptographically protects confidentiality and integrity across the session. ¹

Does encrypting traffic “in transit” with TLS automatically satisfy integrity protection?

Properly configured cryptographic mechanisms protect both confidentiality and integrity for the session traffic. Your audit risk is configuration drift, weak protocol versions, or termination points that expose plaintext downstream. ¹

Are third-party support sessions in scope?

Yes, if a third party can remotely access your systems, that is remote access in practical terms and must be protected with approved encryption. Document the tool, the session path, and how you enforce encryption and logging. ²

What evidence is most persuasive to an assessor?

A remote access inventory, enforced configurations on gateways/bastions, firewall rules that prevent plaintext exposure, and repeatable test outputs that show encryption negotiation and rejection of insecure protocols. Pair those with a short standard and change tickets. ²

How do we handle exceptions for legacy systems that can’t support modern encryption?

Use a documented exception with compensating controls such as isolation, a secured jump host that provides an encrypted outer session, and strict time bounds with an upgrade plan. Keep approvals and technical details in the exception register. ²

How should we scope “remote access sessions” in cloud environments?

Include administrative web consoles, CLI sessions, and remote management actions that administer cloud resources hosting federal data or connected to your regulated environment. Treat identity, session protection, and termination points as part of the remote access pathway. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON