SI-4(22): Unauthorized Network Services

SI-4(22) requires you to detect network services running in your environment that were not explicitly authorized or approved by your organization’s defined authority, then act on that detection through triage, containment, and remediation. To operationalize it, you need an approved service baseline, continuous discovery of services/ports, and auditable workflows for exceptions and enforcement. ¹

Key takeaways:

• Define “authorized network services” with a clear approver, scope, and exception path, then treat anything else as unauthorized until approved.
• Implement continuous service discovery (host + network) and alerting mapped to an incident/ticket workflow with closure criteria.
• Retain evidence that shows the baseline, detections, investigations, and remediation outcomes across representative systems.

The si-4(22): unauthorized network services requirement is an operational control, not a policy-only checkbox. Auditors and assessors will look for a repeatable way to find services that appear on endpoints and network segments without approval, and for proof that your team consistently investigates and resolves them. In practice, “unauthorized services” includes both obvious items (rogue remote admin tools, peer-to-peer services, shadow IT servers) and mundane ones (debug listeners, default services enabled by OS images, temporary services left behind by troubleshooting).

The fastest path to a defensible implementation is to (1) name the authority that approves services, (2) create a baseline of allowed services by system role and network zone, (3) continuously discover what is actually running, and (4) route exceptions through a documented review process. This page gives requirement-level guidance you can hand to an infrastructure lead or SOC manager and then audit against.

Sources for the control language and framework context are NIST’s published NIST SP 800-53 Rev. 5 materials. ²

Regulatory text

NIST SI-4(22) excerpt: “Detect network services that have not been authorized or approved by [organization-defined approval authority]; and” ¹

Operator translation:
You must have a mechanism to identify network-reachable services running in your environment that are not on an approved list (or not approved for that specific system/zone). The control is satisfied by detection plus a demonstrated operational response path (investigate, validate business need, approve or remove). Your implementation needs to show who can approve a service, how approvals are recorded, how detection happens, and how you prevent repeat occurrences. ¹

Plain-English interpretation (what “unauthorized network services” means)

A “network service” is any process that accepts network connections (inbound or outbound), typically exposed via ports/protocols (e.g., SSH, RDP, SMB, HTTP, database listeners), agent-based services (remote management), or application services (custom APIs). “Unauthorized” means it is not approved for:

• that system’s role (e.g., workstation vs. server),
• that network zone (e.g., DMZ vs. internal),
• that environment (e.g., prod vs. dev), or
• that data sensitivity boundary (e.g., systems handling federal data).

Approval must come from your defined authority (commonly IT operations + security, or a change advisory process). If you cannot show an approval record, treat it as unauthorized until reviewed. ¹

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 is in scope through program requirements, contracts, or internal policy mappings. ³

Operational scope

• Endpoints (workstations, laptops) where local services can expose ports.
• Servers (on-prem and cloud) where services may be installed intentionally or accidentally.
• Cloud workloads (IaaS/PaaS) where security groups may expose listeners.
• Network devices and appliances that may run management services.
• Third-party managed environments where you still have governance responsibilities; you may need contractual requirements and shared evidence.

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

1) Define the approval authority and approval objects

Create a short standard that answers:

• Who can approve a network service (role/title or committee).
• What “approval” applies to (service name, port, protocol, process, system role, network zone, environment).
• How exceptions work (temporary approval, compensating controls, expiration, owner).

Implementation tip: If your environment is large, approve services by system class (e.g., “Windows workstation baseline,” “Linux web server baseline,” “Database server baseline”) instead of per-host approvals, then add a narrow per-host exception mechanism.

2) Build an “authorized services baseline” that can be audited

You need an artifact that an assessor can read and an engineer can execute against. Include:

• Allowed inbound services per system class/zone (service + port/protocol).
• Allowed outbound services where it materially affects risk (e.g., egress controls for restricted zones).
• Default-deny stance for anything not listed.
• Ownership for each baseline (who maintains it, how changes are approved).

Make it operational: Tie each allowed service to a justification category (business function, management requirement, monitoring requirement). Avoid free-form text only; make it structured enough to compare to scan results.

3) Implement continuous detection using two lenses: host-based and network-based

Detection should not rely on a single method.

Host-based detection (what’s listening)

• Use endpoint management/EDR/agent inventory to enumerate listening ports and services.
• Confirm process name, binary path, package/source, and running user where possible.

Network-based detection (what’s reachable)

• Use authenticated vulnerability scanning where possible, plus unauthenticated port discovery from representative network vantage points.
• Include cloud perimeter checks (security group exposure and load balancer listeners) and internal east-west visibility where feasible.

Governance requirement: Detection must be frequent enough that unauthorized services are found before they become long-lived “unknown knowns.” Choose a cadence your tooling supports and document it as part of the procedure.

4) Create a triage workflow with clear decision points

Route detections into an operational queue (SOC, IR queue, or ITSM). Each alert/ticket should capture:

• Asset identity (hostname, instance ID), owner, environment, zone.
• Detected service details (port/protocol, process, exposure scope).
• Evidence snapshot (scan output, agent telemetry, firewall logs).

Decision matrix (use this in your runbook):

Condition	Action	Closure criteria
Service is approved for this system class and zone	Mark as authorized	Baseline match documented
Service is legitimate but not yet approved	Initiate exception/approval	Approval record created and baseline updated (or time-bound exception logged)
Service is not legitimate or not needed	Remove/disable service	Verification scan/telemetry shows service no longer listening
Service indicates compromise (e.g., unexpected remote admin)	Escalate to incident response	IR ticket, containment, forensic steps documented

5) Enforce: remove, block, or constrain unauthorized services

Detection alone is weak if services persist. Add enforcement controls appropriate to your environment:

• Configuration management baselines (hardening) that disable unneeded services.
• Host firewall rules to block unauthorized listeners.
• Network segmentation and firewall policy to limit exposure paths.
• Cloud policy-as-code guardrails to prevent opening new listeners without review.

6) Prevent recurrence with change control and “gold image” hygiene

Most repeat findings come from:

• inherited OS defaults,
• “temporary” debugging services,
• admin convenience installs,
• CI/CD pipelines opening ports.

Address this by:

• updating golden images and IaC modules,
• adding pre-deployment checks (open-port tests in CI),
• requiring change tickets for opening inbound services.

7) Map ownership and recurring evidence (make it assessable)

NIST controls fail in audits when nobody “owns” recurring evidence. Assign:

• Control owner (CCO/GRC accountable, ops responsible).
• Evidence owner (SOC/IT operations).
• Review cadence (policy-defined).
• Tooling source of truth.

Daydream fits naturally here as the place you map SI-4(22) to a named owner, documented procedure, and recurring evidence artifacts so the control runs the same way every cycle and is easy to produce during an assessment. ¹

Required evidence and artifacts to retain

Retain artifacts that show design, operation, and results:

1. Design / governance

• Approved “authorized network services baseline” by system class/zone.
• Named approval authority and exception process (runbook or standard).
• Change control record template fields (what must be documented for service approvals).

2. Operational evidence (detection)

• Scan schedules/configuration showing scope (subnets, accounts, environments).
• Representative scan results showing discovered open ports/services.
• Agent/EDR reports listing listening services on sampled endpoints/servers.

3. Operational evidence (response)

• Tickets/cases for unauthorized service detections with disposition.
• Approvals/exceptions with expiry and compensating controls.
• Remediation proof: before/after scan outputs, service disable logs, configuration commits.

4. Oversight

• Periodic review notes: trends, repeat offenders, baseline updates, risk acceptances.

Common exam/audit questions and hangups

• “Who is the organization-defined approval authority for network services?” ¹
• “Show me the authorized services list for this server type and where it’s approved.”
• “How do you detect unauthorized services across cloud and on-prem?”
• “How do you prove you investigated and closed these detections?”
• “How do you handle exceptions and ensure they expire or get re-approved?”
• “Do your scans see internal-only exposure, or only perimeter exposure?”

Hangup that causes findings: teams show a vulnerability scanner report but cannot show an approval baseline or a workflow that distinguishes “known/approved” from “unknown/unauthorized.”

Frequent implementation mistakes (and how to avoid them)

1. Baseline exists only as tribal knowledge.
   Fix: publish a baseline per system class/zone with an approver and version control.

2. Scanning only from one vantage point.
   Fix: include at least one internal perspective and one perimeter perspective, plus host-based telemetry where possible.

3. Treating exceptions as permanent.
   Fix: require an owner, justification, and an expiration date, then track renewals.

4. No closure evidence.
   Fix: require a validation step (rescan or agent confirmation) as a ticket closure criterion.

5. Cloud listeners bypass the process.
   Fix: gate security group/load balancer changes through change control or policy checks.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, unauthorized services create direct attack paths (unexpected remote access, data exposure, lateral movement) and create assessment risk because assessors can independently find open services during testing and ask why they were not approved. ³

A practical 30/60/90-day execution plan

First 30 days (stabilize governance and get visibility)

• Name the approval authority and publish the approval/exception workflow.
• Define initial baselines for your highest-risk system classes (internet-facing, privileged admin networks, systems handling federal data).
• Turn on service discovery from existing tools (scanner + EDR/asset inventory).
• Start ticketing for findings with required fields and closure criteria.

Days 31–60 (reduce noise, improve accuracy, drive remediation)

• Tune detections against the baseline to reduce false positives.
• Fix recurring sources: golden images, IaC modules, default services.
• Add validation steps and reporting (open findings, aging, repeat hosts).
• Formalize exception expirations and re-approval checks.

Days 61–90 (institutionalize and harden)

• Expand baselines to remaining system classes and network zones.
• Add preventive controls: CI checks, configuration enforcement, cloud guardrails.
• Run a mock assessment: sample tickets, approvals, and proof of closure.
• Map SI-4(22) in Daydream (or your GRC system) to owners, procedures, and recurring evidence so audits become a retrieval exercise, not a scramble. ¹

Frequently Asked Questions

Does SI-4(22) require blocking unauthorized services, or only detecting them?

The cited text explicitly requires detection of services not authorized by your approval authority. A defensible implementation also shows what you do after detection, because assessors will test whether findings are resolved and prevented from recurring. ¹

What counts as “approval authority” in practice?

It can be a change advisory board, a security-approved standard with delegated approvers, or an IT operations leader with defined responsibility. Document the role and the mechanism that records approvals so you can show it during assessment. ¹

We have thousands of servers. Do we need approvals per host?

Approve services by system class and zone, then manage deviations through exceptions tied to a business owner. Auditors typically accept this if the baseline is explicit and exceptions are controlled and reviewable.

How do we handle third-party managed systems where we can’t run our scanners?

Put service visibility and unauthorized-service notification requirements into the third party contract/SOW, require periodic attestation plus evidence samples, and reserve audit rights. Treat missing evidence as a risk that needs mitigation or compensating controls.

Are outbound services in scope, or only inbound listening services?

The control text says “network services,” which many teams operationalize around listening services because they create immediate exposure. If outbound services are part of your threat model (restricted zones, data exfiltration concerns), include them in the baseline and detection approach.

What evidence is most persuasive to an assessor?

A readable baseline, a repeatable discovery method, and several closed tickets that show detection, investigation, approval or removal, and verification. Assessors respond well to clear traceability from “found” to “fixed.” ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5