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

SA-4(9) requires you to make the developer (or supplier) of each system, component, or service identify what functions it performs and exactly which ports, protocols, and services it is intended to use in your environment. Operationalize it by baking this disclosure into acquisition and onboarding, validating it during implementation, and retaining a traceable “allowed communications and services” record tied to security approvals.

Key takeaways:

• Put “functions/ports/protocols/services in use” disclosure into contracts, SOWs, and procurement intake so you can enforce it.
• Convert developer-provided details into an approved allowlist and enforce it with technical controls (firewalls, security groups, service disablement).
• Keep evidence that links disclosure → review/approval → implemented configuration → drift monitoring.

SA-4(9) sits in the System and Services Acquisition (SA) family and is easiest to think of as a supply chain transparency requirement with a direct operational payoff: you cannot restrict or monitor what you do not have enumerated. For a CCO or GRC lead, the fastest path is to treat this as a procurement-to-production control with a clean handoff from developers/third parties to engineering.

The “developer” language is broader than it sounds. It includes internal development teams, commercial software suppliers, managed service providers, cloud service configurations you adopt, and integrators that assemble components into a deliverable. Your job is to force a clear statement of intended network exposure (ports/protocols), runtime dependencies (services), and functional scope (what the system actually does), then ensure your organization only enables what was approved.

This requirement also reduces downstream audit friction. Assessors commonly ask for justification of open ports, evidence that unnecessary services are disabled, and proof that your documented architecture matches production reality. SA-4(9) gives you the requirement hook to collect the right information early, keep it current through changes, and demonstrate controlled implementation using repeatable artifacts.

Regulatory text

Requirement (SA-4(9)): “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 (1) compel the developer/supplier to provide a complete, accurate identification of intended functions and communications/service interfaces, and (2) treat that identification as an input to your security review and implementation. Practically, this means your acquisition and onboarding process must collect this information in a structured way, and your engineering teams must configure the deployed system to match the approved set.

Plain-English interpretation

SA-4(9) means: Before you approve and deploy a system (or a material component/service), you need a developer-provided inventory of what it does and what it needs enabled to run:

• Functions: capabilities and feature set you are expected to use (and sometimes what you are explicitly not using).
• Ports: listening ports and outbound ports required.
• Protocols: network protocols used (for example, TLS over TCP, SSH, SNMP, database protocols).
• Services: operating system services, application services, daemons, APIs, agents, and supporting components that must run.

Your organization then uses this to drive least functionality and least privilege for network exposure: only enable what is necessary and approved.

Who it applies to

Entity scope

• Federal information systems and contractors handling federal data, or any organization adopting NIST SP 800-53 as a control baseline ².

Operational scope (where this shows up)

• New acquisitions: COTS software, SaaS, PaaS/IaaS architectures, appliances, endpoints, security tools.
• System changes: new integrations, new modules, feature flags, enabling admin interfaces, agent rollouts.
• Third-party delivered services: managed services, hosting, SOC/MDR sensors, payment components, identity providers.
• Internal development: major releases and new services that introduce new ports/protocols, or new dependency services (message queues, caches, databases).

If you have a CMDB, asset inventory, SSP, or architecture repository, SA-4(9) should feed those records.

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

1) Define the “developer disclosure” intake (make it non-optional)

Create a standard intake form (or ticket template) that requires, at minimum:

• System/component/service name and version
• Intended functions/capabilities enabled for your deployment
• Inbound listening ports (by interface), outbound ports, and directionality
• Protocols for each port (and whether encrypted/authenticated)
• Required services/processes and any optional services that should be disabled
• External dependencies (DNS, NTP, SMTP relays, IDP endpoints, update servers)
• Administrative interfaces (ports, protocols, network ranges allowed)
• Logging/telemetry endpoints and protocols

Control design tip: treat “unknown” as a blocker for go-live, or force a documented exception with compensating controls.

2) Put the requirement into procurement and third-party onboarding

For third parties and suppliers, embed SA-4(9) into:

• Contract language / MSA addendum
• SOW deliverables and acceptance criteria
• Security questionnaire and onboarding checklist

Make the deliverable concrete: “Provide a ports/protocols/services matrix for the delivered system and any agents/components.”

3) Convert disclosure into an approved allowlist (security decision)

Route the disclosure to the right approvers:

• Security architecture / network security for port/protocol review
• Platform/infra owners for service hardening (disable non-required services)
• AppSec for exposed services/APIs and auth requirements
• Data protection/privacy if functions affect data flows

Output artifact: an Approved Communications & Services Profile that states:

• Allowed inbound/outbound flows (source, destination, port, protocol)
• Allowed running services/components
• Prohibited/disabled services
• Required secure configurations (for example, “admin UI only on management network”)

4) Implement technical enforcement

Translate the approved profile into enforceable config:

• Firewall rules, security groups, NACLs
• Kubernetes NetworkPolicies / service mesh policy (if relevant)
• Host-based firewall config
• System hardening and service disablement
• Load balancer listeners and WAF rules
• EDR/MDR agent configuration (ensure it doesn’t open unapproved listeners)

Practical check: engineering should be able to point to the exact rule sets or IaC pull requests that implement the allowlist.

5) Validate in a deployment gate (don’t rely on paperwork)

Add a verification step before production:

• Port scan or service discovery for exposed interfaces
• Configuration review to confirm services are disabled/enabled as approved
• Compare detected open ports against the approved profile
• Document discrepancies and remediation

6) Manage drift with change control and recurring checks

SA-4(9) fails quietly when:

• teams enable a new feature that starts a new listener,
• a patch introduces a new service,
• an integration adds outbound calls to new endpoints.

Tie updates to:

• Change management: any change that modifies ports/protocols/services triggers re-review.
• Periodic control health checks: sample systems and confirm “as-built” matches “as-approved.”

7) Operationalize with a control card and evidence bundle

To make this auditable and repeatable, maintain:

• A “control card” (objective, owner, trigger events, execution steps, exceptions)
• A defined minimum evidence bundle per execution cycle

This is where Daydream typically fits cleanly: teams use Daydream to standardize the control card, collect the evidence bundle from intake through approval, and track remediation items to closure across systems and third parties without losing the thread.

Required evidence and artifacts to retain

Retain artifacts that prove developer identification happened and you implemented what was approved:

Developer/Supplier outputs

• Ports/Protocols/Services matrix (versioned)
• Architecture or deployment guide sections covering networking and services
• Statement of intended functions (feature set enabled for your use)

Your organization’s approvals

• Security review/architecture sign-off referencing the matrix
• Risk acceptance records for any exceptions (who approved, scope, rationale)
• Change tickets linking to updated matrices and approvals

Implementation proof

• Firewall/security group configurations (export or IaC change record)
• Hardening checklists showing disabled services
• Validation results (scan outputs, service discovery results)
• Configuration baselines (gold images, CIS-style hardening outputs if you use them)

Operations

• Drift monitoring evidence (alerts, periodic review logs)
• Inventory/SSP/architecture repository entries reflecting approved ports/protocols/services

Common exam/audit questions and hangups

Auditors and assessors usually probe these areas:

1. “Show me where the developer identified the ports/protocols/services.”
   Hangup: teams only have a generic admin guide, not a system-specific disclosure.

2. “Which ports are open in production and why?”
   Hangup: the list exists, but there’s no approval record or business justification.

3. “How do you ensure only approved services run?”
   Hangup: hardening is ad hoc; no baseline or disablement evidence.

4. “How do you keep it current after updates?”
   Hangup: no trigger in change management, so the matrix drifts from reality.

5. “Does this include outbound traffic and dependencies?”
   Hangup: teams focus on inbound listeners and ignore egress and third-party endpoints.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Avoid it by
Treating SA-4(9) as documentation-only	You can document anything; audits ask if it matches production	Require validation (scan/config review) and keep results
Only capturing inbound ports	Many incidents and data flows are outbound	Require egress ports, destinations, and protocols in the intake
Letting “developer” mean “internal dev only”	Commercial products and managed services introduce interfaces	Put SA-4(9) deliverables into third-party onboarding and contracts
Missing admin interfaces	Management ports are high-risk	Require explicit admin interface listing and network restrictions
No change trigger	Patches/features add services silently	Add a change control trigger for any new ports/protocols/services

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The operational risk is still straightforward: if you cannot account for functions, ports, protocols, and services in use, you will struggle to (a) justify exposure during assessments, (b) enforce least functionality, and (c) detect unauthorized changes that expand attack surface. SA-4(9) also strengthens third-party due diligence because it forces suppliers to be explicit about what must be enabled in your environment.

A practical 30/60/90-day execution plan

First 30 days (foundation and intake)

• Assign an owner (usually Security Architecture or GRC with Network/Platform co-owners).
• Publish a single intake template for functions/ports/protocols/services.
• Update procurement/onboarding checklists to require the developer disclosure before implementation begins.
• Define the minimum evidence bundle and where it is stored (ticketing system, GRC tool, repository).

Days 31–60 (pilot and technical enforcement)

• Pilot on a small set of systems: one internal service, one COTS product, one third-party managed service.
• Create an “Approved Communications & Services Profile” format and get it accepted by security/network teams.
• Implement enforcement via security groups/firewalls and service hardening for pilot systems.
• Add a validation gate (scan/config review) to the release process for the pilot scope.

Days 61–90 (scale and sustain)

• Roll out the intake + approval workflow across all new acquisitions and major changes.
• Connect change management: any request that alters ports/protocols/services must attach an updated matrix and approval.
• Stand up recurring drift checks and a remediation workflow with tracked closure.
• Build an audit-ready register: for each in-scope system, link developer disclosure → approval → implemented configuration → validation evidence.

Frequently Asked Questions

Does SA-4(9) apply to SaaS where we can’t see the underlying ports and services?

Yes, but you scope it to what the supplier can reasonably disclose and what you control. Require documentation of exposed interfaces, integration methods, network requirements (IP allowlists, endpoints), and any agents/connectors you deploy.

Who counts as the “developer” for a commercial off-the-shelf product?

The product supplier is the developer for SA-4(9) purposes, and an integrator can also be a “developer” for the assembled solution. Your procurement language should bind whichever party delivers the system/component/service to provide the identification.

Do we need to list every ephemeral port used by clients?

Focus on intended, required communications and services for organizational use: listening ports, required egress destinations/ports, and named protocols. If ephemeral ports are part of a documented dependency pattern, capture the constraint (for example, “client ephemeral range outbound”) and enforce it where feasible.

How is this different from firewall rule documentation?

Firewall documentation is your enforcement output. SA-4(9) starts earlier and requires the developer’s identification as an input, then you translate it into approved allowlists and implemented controls.

What if the third party refuses to provide a ports/protocols/services list?

Treat it as a due diligence failure and escalate as a risk decision. If you proceed, document an exception with compensating controls (segmentation, restricted egress, enhanced monitoring) and set a deadline for the third party to provide the missing disclosure.

How do we keep the record current without creating heavy process overhead?

Make it event-driven. Tie updates to change triggers (new integration, new feature/module, version upgrades, network architecture changes) and require re-attestation from the system owner during normal release/change workflows.

Footnotes

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

2. NIST SP 800-53 Rev. 5