AC-17(8): Disable Nonsecure Network Protocols

AC-17(8) requires you to disable nonsecure network protocols for remote access and management so users, admins, and systems cannot fall back to cleartext or weakly protected communications. Operationalize it by inventorying where legacy protocols exist, blocking them at network and host layers, forcing secure alternatives (for example, SSH and TLS), and retaining evidence that the blocks are enforced and monitored. ¹

Key takeaways:

• You must identify and shut off insecure protocols end-to-end (client, server, network devices, and management planes), not just “prefer” secure ones.
• Auditors look for proof of enforcement (configs, scans, change records), plus an exception process for the rare cases you cannot fully eliminate.
• Treat this as a remote access and administrative pathway control; prioritize externally reachable services and privileged management channels. ¹

The ac-17(8): disable nonsecure network protocols requirement is straightforward in wording but easy to fail in execution because “nonsecure protocol” lives in many places: legacy device management interfaces, old file transfer methods, default cloud images, and “temporary” debug services that stay open. If your organization supports federal information systems or operates contractor systems that handle federal data, you need to show that insecure protocols are intentionally disabled and that secure alternatives are enforced. ¹

For a CCO, GRC lead, or compliance owner, the goal is quick operational clarity: define what “nonsecure” means in your environment, find every place it exists, disable it with technical controls that actually prevent use, and build an evidence package that stands up in an assessment. This page gives you a requirement-level interpretation, a step-by-step implementation approach, the artifacts to retain, and the audit questions that commonly stall control testing. It also includes a practical execution plan and real-world FAQs you can hand to engineering and infrastructure teams.

Regulatory text

Control: AC-17(8) Disable Nonsecure Network Protocols.
Provided excerpt: “NIST SP 800-53 control AC-17.8.” ²

What the operator must do: Implement remote access in a way that prevents the use of nonsecure network protocols. In practice, that means you (1) determine which protocols are prohibited for remote access and administrative pathways, (2) technically disable them so they cannot be used, and (3) keep evidence that the disabling is implemented, enforced, and maintained over time. ¹

Plain-English interpretation (what AC-17(8) is asking for)

“Disable” means a user cannot successfully connect using an insecure protocol even if they try. “Nonsecure network protocols” are protocols that transmit sensitive data (credentials, sessions, content) without adequate cryptographic protection, or that are known to be weak for modern remote access. Your implementation should not rely on user behavior (“don’t use Telnet”) or a preference order (“SSH is first, Telnet is second”). It should hard-block insecure options and require secure alternatives. ¹

Common “nonsecure” protocols (use as a starting list)

Your environment may differ, but these are frequently in scope for disabling on remote/admin paths:

• Telnet for remote shell
• FTP and “plain” file transfer services without TLS
• HTTP for administrative consoles or management portals (when HTTPS is available)
• SNMPv1/v2c for device management (prefer SNMPv3 where needed)
• Legacy remote desktop configurations that do not enforce strong encryption

You do not need to overreach into every internal application protocol on day one. Start where AC-17 lives: remote access, privileged administration, and management planes.

Who it applies to

Entity scope:

• Federal information systems
• Contractor systems handling federal data ²

Operational scope (where teams usually implement it):

• Remote access services: VPNs, ZTNA, bastions/jump hosts, remote support tools
• Administrative interfaces: hypervisor consoles, network device management, storage arrays, database admin consoles
• Cloud control planes and APIs (as configured by your org), plus access paths to cloud workloads
• Third-party managed services where the third party administers your environment (you still need contractual and technical assurance)

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

1) Name the control owner and write the rule in plain language

Assign an accountable owner (often Network/Security Engineering) and publish a short standard:

• “Nonsecure protocols are prohibited for remote access and management.”
• “Only approved secure protocols are allowed.”
• “Exceptions require risk acceptance and compensating controls.”

This matters because auditors will ask who is responsible and how the requirement is maintained, not just how it was configured once.

2) Build an inventory of remote/admin entry points

Create a list of all paths that allow remote connectivity or management:

• Internet-facing and partner-facing IPs/DNS names
• VPN/remote access gateways
• Bastion hosts and admin jump boxes
• Network devices and controllers
• Remote management interfaces (iDRAC/iLO/IPMI, BMCs)
• Managed service access methods (how the third party connects)

Practical method: combine CMDB/asset inventory with network discovery and a review of firewall/security group rules.

3) Define your “allowed protocols” list (the enforcement baseline)

Make an explicit allowed list for remote/admin functions, such as:

• SSH for shell access
• TLS-protected web admin (HTTPS) with strong configuration
• SFTP/SCP or other encrypted file transfer
• SNMPv3 if SNMP is required

Keep it short. The longer the list, the harder it is to prove control and spot drift.

4) Disable nonsecure protocols at multiple layers (defense in depth)

Relying on a single control point is fragile. Implement blocks in at least two places:

Network layer (preferred first):

• Firewalls: block ports/services associated with nonsecure protocols
• Cloud security groups/NACLs: deny insecure management ports
• Segmentation: ensure management networks are not reachable from user networks or the internet

Host/service layer (required for strong assurance):

• Disable daemons/services for insecure protocols
• Enforce secure configuration on the secure alternative (for example, disable HTTP when HTTPS is enabled)
• Remove packages/modules that re-enable legacy services

Administrative tooling layer:

• Endpoint management policies that prevent admins from using insecure clients
• Bastion configurations that only allow approved protocol forwarding

5) Handle the unavoidable exceptions with a tight process

Some legacy equipment or third-party dependencies may require a nonsecure protocol temporarily. Treat each as an exception with:

• Business justification and scope (system, ports, source IP ranges)
• Compensating controls (segmentation, jump host, time-bound access, monitoring)
• Expiration date and remediation plan

Auditors are often more comfortable with a controlled exception than a hidden gap.

6) Validate with testing, not assumptions

Validation should prove the protocol is disabled:

• Attempted connection tests (from an admin network and from a non-admin network)
• Port scanning of defined management subnets and internet exposure
• Configuration reviews for key device classes (routers, firewalls, bastions, golden images)

Make validation repeatable. Tie it to change management and periodic security testing.

7) Monitor for drift and reintroduction

Nonsecure protocols commonly reappear after:

• Device replacements
• Emergency troubleshooting
• New cloud deployments from default images
• Third-party onboarding

Add detections:

• Security scanning rules for prohibited ports/services
• Configuration compliance checks for network devices and server baselines
• Alerts when firewall rules open prohibited ports

8) Map to control documentation and recurring evidence

This is where many teams fail AC-17(8): the technical work exists, but evidence is scattered. Centralize it. Daydream is often used here to map AC-17(8) to an owner, a documented procedure, and recurring evidence artifacts so assessments do not turn into a ticket hunt. ²

Required evidence and artifacts to retain

Keep evidence that shows design, implementation, and ongoing operation:

Policy/standard

• Remote access standard listing prohibited and allowed protocols
• Exception/risk acceptance template and approval workflow

Technical configurations (representative samples)

• Firewall/security group rules showing blocked services
• Device configs showing Telnet/HTTP/FTP disabled where applicable
• Bastion/jump host configuration enforcing allowed protocols

Validation results

• Scan reports (internal and external where relevant) showing prohibited ports closed
• Test records for attempted connections failing for nonsecure protocols

Operational governance

• Change tickets for protocol disablement work
• Exception register with expiration dates and compensating controls
• Monitoring alerts/detection rules for prohibited services

Tip: Organize artifacts by “remote access pathway” (VPN, bastion, network devices, cloud) because that matches how assessors ask questions.

Common exam/audit questions and hangups

Expect these and prepare crisp answers:

1. “Define ‘nonsecure’ in your environment.”
   Have a written prohibited protocol list tied to remote/admin use cases.

2. “Show me it’s disabled, not just discouraged.”
   Provide configs plus a scan/test result that demonstrates failure to connect.

3. “How do you prevent reintroduction?”
   Show monitoring, configuration compliance checks, and change controls.

4. “What about third parties who administer your systems?”
   Show contract language or access architecture (bastion, dedicated VPN) that restricts them to secure protocols.

5. “What exceptions exist and who approved them?”
   Produce an exception register with time bounds and compensating controls.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Blocking at the perimeter only. A flat internal network can still allow Telnet/FTP east-west.
  Avoidance: disable on hosts/devices and segment management networks.

• Mistake: Treating “encrypted option available” as compliant. HTTP still enabled alongside HTTPS is a common fail.
  Avoidance: explicitly disable the insecure listener/redirect, and prove the port is closed.

• Mistake: No evidence of ongoing operation. One-time screenshots won’t survive an assessment.
  Avoidance: schedule recurring scans and retain last-run results plus alert logic.

• Mistake: Exceptions without expiration. “Temporary” becomes permanent.
  Avoidance: require an end date and a plan, then review exceptions on a fixed cadence.

Enforcement context and risk implications

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

From a risk standpoint, nonsecure protocols create credential exposure, session hijacking risk, and administrative compromise paths. Assessors focus on AC-17(8) because remote access and management planes are common initial access routes, and insecure protocols remove cryptographic safeguards that help contain that risk. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Assign control owner and publish prohibited/allowed protocol baseline for remote/admin access.
• Identify all remote/admin entry points (VPN, bastions, device management, cloud security groups).
• Block the most dangerous externally reachable insecure services at the perimeter and in cloud edge controls.
• Stand up an exception process so engineering does not bypass compliance to get work done.

Next 60 days (disable at the source and prove it)

• Disable insecure services on servers, network devices, and management interfaces based on the inventory.
• Standardize hardened configs (golden images, device templates) so new deployments inherit secure settings.
• Run a repeatable validation scan and store results as evidence.
• Document compensating controls for any exceptions and constrain them (source IPs, time windows, jump hosts).

By 90 days (operate it as a control, not a project)

• Add monitoring/detections for prohibited ports and services, and route alerts to an accountable queue.
• Integrate checks into change management for network/security group modifications.
• Produce a single control evidence packet: policy, baseline, configs, scan results, exception register, and monitoring proof.
• If you use Daydream, map AC-17(8) to the owner, procedure, and recurring evidence requests so audits pull from a system of record rather than ad hoc exports. ²

Frequently Asked Questions

What counts as a “nonsecure network protocol” for AC-17(8)?

Treat protocols as nonsecure when they allow remote/admin access without strong cryptographic protection for authentication and session data. Define your prohibited list in a standard, then enforce it technically with blocks and service disablement. ¹

Is it enough to “prefer” secure protocols (for example, allow both HTTP and HTTPS)?

No. If the insecure protocol is still available, users and tools can still connect with it. Disable the insecure listener/port and keep scan evidence that it’s closed.

How do we handle legacy systems that only support an insecure protocol?

Use a formal exception with compensating controls like segmentation, a jump host, strict source IP allowlisting, and enhanced monitoring. Put an expiration date and a replacement plan in the exception record.

Does AC-17(8) apply to internal-only networks?

It applies to remote access and management pathways, which can be internal (admin networks) as well as external. Scope it to where remote connectivity and administration occur, then prioritize the most exposed paths first. ¹

What evidence is strongest in an audit for this control?

Combine (1) written standards defining prohibited/allowed protocols, (2) configs showing services disabled and ports blocked, and (3) validation output (scan/test results) showing the insecure ports are not reachable.

How should we manage third-party administrators under this requirement?

Force third-party access through your approved secure entry points (for example, a bastion or controlled VPN) and prohibit direct management-plane access over nonsecure protocols. Keep contract terms, access architecture diagrams, and logs as supporting evidence.

Footnotes

1. NIST SP 800-53 Rev. 5

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