SA-4(9): Functions, Ports, Protocols, and Services in Use

The sa-4(9): functions, ports, protocols, and services in use requirement is a supply chain and system engineering control disguised as a documentation ask. If you accept a system without a clear, developer-provided inventory of intended functions and network/service exposure, you create predictable failure modes: open ports that no one owns, “temporary” services that become permanent, and inconsistent rules between environments.

SA-4(9) sits in the System and Services Acquisition (SA) family, so auditors usually expect to see it integrated into acquisition and development lifecycle gates, not handled as an after-the-fact spreadsheet. For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) define a standard deliverable that developers must provide, (2) require it for onboarding/changes, and (3) validate it against what is actually deployed.

This page gives requirement-level implementation guidance you can hand to engineering, procurement, and security operations with minimal translation, while keeping you assessment-ready against NIST SP 800-53 Rev. 5 expectations. ¹

Regulatory text

Requirement (verbatim): “Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.” ²

What the operator must do: you must make it a condition of acceptance that the developer provides an explicit statement of:

• Functions the system/component/service performs (what it is supposed to do)
• Ports it expects to listen on or connect to
• Protocols used over those ports (for example, TCP/UDP, and application protocols)
• Services that must be enabled to support the intended functions (OS services, daemons, application services, managed cloud services)

This is not satisfied by “we run in Kubernetes” or “it’s a web app.” Assessors look for an explicit, reviewable list, tied to the specific system and deployment context. ¹

Plain-English interpretation

You are requiring the builder to tell you, in concrete technical terms, what they are putting on your network and what it needs to operate. That list becomes your enforceable baseline for:

• Network allowlisting (firewalls, security groups, load balancers, WAF paths where relevant)
• Hardening (disable anything not on the list)
• Monitoring and scanning scope (if it’s in use, it should be monitored; if it’s not intended, it should be blocked or removed)
• Change control (any new port/protocol/service is a change that needs review)

A useful mental model: SA-4(9) is “developer-declared attack surface.” Your job is to require the declaration and ensure your environment matches it.

Who it applies to

Entities: Federal information systems and contractor systems handling federal data commonly inherit this expectation through NIST SP 800-53-based programs. ¹

Operational context (where auditors will care most):

• New system onboarding into production (internal apps, SaaS integrations, COTS tools, appliances)
• Major releases, architecture changes, re-platforming (for example, VM to containers, on-prem to cloud)
• Third-party provided components/services (managed service providers, hosted platforms, outsourced development)
• High-impact boundary zones (internet-facing services, remote access paths, admin interfaces)

Teams you’ll need involved:

• Product/engineering (owns “functions” and application services)
• Infrastructure/cloud/network (owns ports/protocol exposure and enforcement points)
• Security engineering/architecture (approves baseline and exceptions)
• Procurement/vendor management (makes it contractual for third parties)
• GRC/compliance (defines evidence standard and audit trail)

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

Step 1: Define the SA-4(9) deliverable (one pager, enforceable)

Create a standard template developers must complete for each system/component/service. Minimum fields:

• System name, environment(s), owner, data sensitivity tier
• Intended functions (brief, user-facing and admin-facing)
• Inbound ports/protocols/services (listener ports, management ports)
• Outbound ports/protocols/services (egress dependencies)
• East-west dependencies (service-to-service calls)
• Authentication and encryption expectations per protocol (high level; don’t turn SA-4(9) into a full TLS standard)
• “Not in use” statement (explicitly list what is disabled/blocked by default)
• References: architecture diagram, runbook, IaC repo, container manifests

Practical tip: require both “what” and “where.” A port list without the enforcing control point (security group, firewall policy, ingress controller) is hard to validate.

Step 2: Make it a gate in procurement and intake

For third parties, add SA-4(9) language into:

• RFP security schedules
• Contract exhibits / security addenda
• Statements of Work and acceptance criteria

For internal development, put it into:

• Secure SDLC entry criteria (architecture review intake)
• Change management (CAB) checklist for releases that alter exposure
• Production readiness review checklist

Your policy statement can be simple: “No production deployment without an approved Functions/Ports/Protocols/Services declaration from the developer.” ²

Step 3: Review and approve the declaration (make ownership explicit)

Define approvers and decision rules:

• Engineering owner confirms functional intent and required services.
• Network/cloud owner confirms feasibility and enforcement mechanism.
• Security approves exposure based on least functionality principles (and routes exceptions).

Use a short decision matrix:

Scenario	Default decision	Required action
Internet-exposed listener	Allow only if explicitly listed	Add to external surface inventory; confirm monitoring/alerting owner
Admin/management ports	Block by default	Require bastion/VPN/privileged path; document exception if exposed
New outbound dependency	Allow only if listed	Update egress allowlist and threat modeling notes
“Temporary” debug service	Deny	Replace with approved diagnostics approach; time-bound exception if unavoidable

Step 4: Validate against reality (don’t rely only on the developer’s word)

SA-4(9) is easy to “paper pass” unless you verify. Build a lightweight validation routine:

• Compare declared ports/services to security group rules / firewall rules (desired vs configured).
• Compare declared services to host/container configuration (running processes, enabled services).
• Compare declared protocols to load balancer/ingress configuration and supported ciphers/versions where applicable.
• Confirm vulnerability scanner coverage includes the declared exposed services.

Evidence can come from screenshots, exported rulesets, IaC diffs, or automated configuration reports. The key is traceability: the observed configuration supports the declared intended use. ¹

Step 5: Operationalize change control for drift

Define what triggers an update:

• New listener port, protocol, or externally reachable endpoint
• New outbound connectivity requirement
• Enabling a new OS/application service
• Introducing a new managed service dependency (for example, message queue, cache)

Then set an operational rule: “Changes to declared functions/ports/protocols/services require re-approval before deployment.” Tie it to your ticketing workflow so it’s auditable.

Step 6: Build a recurring evidence motion (assessment-ready)

A practical cadence is event-driven (on change) plus periodic validation (on a schedule you define). Keep it simple: one recurring control test that samples systems and checks “declaration exists, approval exists, configuration matches.” Your schedule can be based on system risk tier.

If you use Daydream, treat SA-4(9) as a control with a clear owner, a repeatable procedure, and recurring artifacts so you can answer “show me” questions quickly without chasing engineers for screenshots. ²

Required evidence and artifacts to retain

Retain artifacts that prove (a) the developer identified the items and (b) you enforced/validated them.

Core artifacts (minimum):

• Completed developer declaration (template) for each in-scope system/component/service
• Approval record (ticket, change request, architecture review sign-off)
• Network enforcement evidence (security group/firewall policy export or IaC config)
• Service configuration evidence (configuration management report, container/helm manifest, OS service list)
• Exception records (risk acceptance, compensating controls, expiration)

Helpful supporting artifacts:

• Architecture diagram showing ingress/egress paths
• Service catalog entry or CMDB record linking to the declaration
• Test results from port scans or exposure management tools (internal and external, where applicable)

Common exam/audit questions and hangups

Expect these questions in a NIST 800-53 assessment:

• “Show me where the developer identified the ports/protocols/services for System X.” ²
• “How do you ensure only the intended ports are enabled in production?”
• “What triggers an update to this list?”
• “How do you handle third-party products where you don’t control development?”
• “Demonstrate that your firewall/security groups align to the approved list.”

Hangups that slow teams down:

• No single source of truth (lists exist in emails, wikis, and tribal knowledge)
• “Ports” documented, but services and functions are vague
• Approvals happen verbally; nothing is retained
• Different answers per environment (dev vs prod) with no rationale or record

Frequent implementation mistakes and how to avoid them

1. Mistake: treating SA-4(9) as a one-time procurement checkbox.
   Fix: bind it to change management; require re-approval on exposure changes.

2. Mistake: only documenting inbound ports.
   Fix: require outbound dependencies too; egress is part of real-world attack paths and data exfiltration scenarios.

3. Mistake: listing “HTTPS” without specifying where it terminates.
   Fix: record termination point (load balancer, ingress controller, host) and the service that owns it.

4. Mistake: allowing “temporary” admin ports.
   Fix: require a time-bound exception and a removal ticket linked to the approval record.

5. Mistake: failing to validate against deployed configuration.
   Fix: add a simple validation step and retain proof; do not depend on intentions alone.

Enforcement context and risk implications

No public enforcement cases are provided in the source material for this specific enhancement, so you should frame risk in operational terms rather than penalties. The risk is straightforward: undocumented or unreviewed exposure increases the chance of misconfiguration, unauthorized services, and unmonitored entry points. SA-4(9) reduces that risk by forcing early clarity and giving security and network teams a baseline to enforce. ¹

Practical 30/60/90-day execution plan

First 30 days (establish the gate)

• Publish the SA-4(9) template and completion criteria.
• Assign a control owner and approver roles (engineering, network/cloud, security).
• Update one intake workflow: either architecture review or production readiness.
• Add contract/SOW language for third parties for new purchases.

Days 31–60 (prove it works on real systems)

• Pilot on a small set of systems (pick one internet-facing, one internal, one third-party).
• Build the validation routine: compare declarations to security group/firewall rules and running services.
• Create an exception process with an owner and clear expiration handling.
• Train reviewers on what “good” looks like (examples of acceptable declarations).

Days 61–90 (scale and make it auditable)

• Expand coverage by integrating the template into ticketing and change workflows.
• Create a system inventory view that links each system to its current declaration and approval.
• Start recurring control testing and document results with remediation tracking.
• Prepare an audit packet: template, samples, approvals, validation outputs, exceptions.

Frequently Asked Questions

Does SA-4(9) require us to enumerate every ephemeral port used by microservices?

No special port taxonomy is stated in the control text. Require developers to identify intended listener ports and required communications patterns, then document how ephemeral behavior is controlled (for example, through service mesh policy or node security rules). ²

How do we satisfy SA-4(9) for a SaaS provider where we can’t see their internal ports?

Scope the requirement to what matters for your organizational use: integration points, inbound/outbound connectivity from your environment, and any customer-configurable services or endpoints. Put the deliverable into the SaaS security schedule and retain the provider’s documentation/attestation. ¹

Is a network diagram enough evidence by itself?

Usually not. A diagram helps, but auditors will still ask for the explicit list and proof it matches configured enforcement points (security groups/firewalls/ingress). Keep both the declaration and the validation output. ¹

Who should own this control: security, network, or engineering?

Make GRC/security own the requirement and evidence standard, while engineering owns content accuracy and network/cloud owns enforcement configuration. SA-4(9) fails when ownership is ambiguous. ¹

What’s the difference between “services” and “functions” in practice?

Functions describe intended capabilities (for example, “serves customer portal traffic”), while services are the enabling technical components (for example, “nginx ingress,” “sshd disabled,” “database listener enabled”). Your template should force both. ²

How do we keep the list current without turning it into busywork?

Tie updates to change triggers you already manage (release approvals, infrastructure changes, new integrations). Then run periodic sampling to catch drift and route fixes through normal remediation. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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