RMFInsider

PPSM registration is how you get a port, protocol, or service formally declared and approved for use on the DoD Information Network. In DoD it is governed by DoDI 8551.01, Ports, Protocols, and Services Management, which requires that every PPS crossing a boundary be declared in the PPSM Registry and be consistent with the Category Assurance List, or CAL. Boundary protection devices are supposed to permit only the PPS you declared. If a service is not covered on the CAL for the boundary it crosses, you either get an exception approved through the PPSM process or you do not run it across that boundary. Registration is not a NIST control on its own, but it is the paper trail behind CM-7 least functionality and SC-7 boundary protection, and an assessor will compare your declared PPS list against your boundary diagram and your actual firewall rules.

What PPSM actually is

PPSM is a DoD-wide cataloging and risk regime for network traffic. DoDI 8551.01 directs the Department to catalog, regulate, and control the protocols and the ports and services that ride on them, across the DODIN. The scope is broad on purpose: it covers systems under development, systems being acquired, systems already in operation, platform IT systems, and individual products.

DISA runs the registry capability. The PPSM Registry lives on SIPRNet, which is the first practical surprise for people who have only ever worked NIPRNet systems. Your component almost certainly has a designated PPSM point of contact who holds the registry account, and the fastest thing you can do on a new program is find out who that is before you need them.

The governance body is the PPSM Configuration Control Board. The CCB reviews change requests, adjudicates non-standard usage, and owns the CAL. Because the CAL changes, anything I write here about a specific port is a snapshot. Pull the current CAL from DoD Cyber Exchange before you build a package around it.

The Category Assurance List and what CAL compliant means

The CAL is the summary reference DoD uses to standardize PPS across the DODIN. Each declared PPS gets an assurance category, which reflects the functional capability of the protocol, the results of a vulnerability assessment, and the operational damage the traffic could cause if abused.

The important nuance: assurance is expressed per boundary crossing, not globally. The same protocol can be acceptable inside an enclave, acceptable with mitigations from a DMZ to an enclave, and unacceptable from the internet. So “is TCP 443 approved” is not a real question. The real question is “is this service over TCP 443 approved across the specific boundary it crosses, and what mitigations does the CAL entry require.”

“CAL compliant” means three things at once, and I have watched programs claim it having satisfied only the first:

• The PPS is listed on the CAL with an assurance category that covers the boundary your traffic actually crosses.
• The mitigations the CAL entry calls for are implemented and documented, not just acknowledged.
• The traffic is registered against your system in the PPSM Registry, with the boundary and the mitigations recorded.

What a PPS registration record has to include

Field names vary a little by component workflow, but the substance the registry and the CCB expect is consistent. Every registration I have helped assemble needed the following:

• System identity: the registered system name, its eMASS or component identifier, the owning organization, and the authorizing official of record.
• The protocol, and the port or port range, and the direction of the flow.
• Source and destination: the enclaves or zones on each end, named the same way your boundary diagram names them.
• Which boundary the traffic crosses, using the boundary types the CAL uses rather than your local shorthand.
• The mission or functional justification, in one or two sentences a network engineer and an authorizing official can both follow.
• The application or service that uses the PPS, with version, so it can be tied back to your inventory.
• Encryption and authentication: what protects the traffic in transit and how endpoints authenticate.
• The mitigations applied, mapped to the mitigations the CAL entry requires.
• Whether an exception is being requested, and if so, the alternative that was considered and rejected.
• A technical point of contact, with the organization and role rather than one person’s name.

If the system is already registered, keep the PPS list, your hardware and software inventory in eMASS, and your firewall rule set in the same change process. When those three drift apart, the assessment finds it.

Who submits it, and who thinks somebody else is doing it

This is where PPSM registrations die. Three groups each have a piece, and none of them owns the whole thing by default.

The program office or system owner owns the declaration. They know the mission need and they fund the work. The ISSO usually assembles the record, because the ISSO is the one person who holds the boundary diagram, the inventory, and the control implementation statements in the same head. The network or transport shop owns the boundary devices and implements the rules, and they often hold the registry account.

Sort out in writing who submits, who approves internally before submission, and who verifies the firewall rule matches the approved record afterward. On the last package I worked, the registration was accurate and the firewall rule was two ports wider than the registration, because the rule was built from an email thread rather than from the record.

How PPSM connects to CM-7 and SC-7

CM-7, least functionality, is the control that says you configure the system to provide only essential capabilities and you prohibit or restrict use of functions, ports, protocols, and services. Your PPSM registration is the authoritative answer to “which ones are essential, and who agreed.” CM-7(1) periodic review and CM-7(5) allow-by-exception both land on the same list.

SC-7 is the other half. The PPSM instruction directs that DoD boundary protection devices, meaning routers, firewalls, and intrusion detection or prevention devices, be configured to permit only approved PPS, and that non-compliant PPS be blocked at the boundary. So the control implementation statement for SC-7 boundary protection should cite the registration, and the registration should describe the same boundary your authorization boundary diagram draws. Three artifacts, one story.

A worked example

Here is one service, written the way it should read in the record.

A patch management server inside the application enclave needs to reach an update service in the management enclave. The flow is TCP 443 outbound from the patch server at one named address to the update service at another named address, crossing an enclave-to-enclave boundary. The service is HTTPS with TLS 1.2 or higher, mutual certificate authentication using DoD PKI. Justification: retrieval of vendor content so SI-2 flaw remediation timelines can be met. Mitigations: destination restricted to a single host rather than a subnet, TLS inspection at the enclave firewall, content validated by signature before installation, and rule reviewed at the quarterly configuration control board.

That is a registration an assessor can trace. The firewall rule is specific enough to compare. The justification names a control. The mitigations are testable rather than aspirational. Contrast that with the version I usually inherit: “443 outbound, any to any, needed for patching.”

Exceptions, banned protocols, and non-standard usage

DoDI 8551.01 provides an exception process for cases where no other suitable alternative exists. Two situations drive it. A protocol may be banned in its native form, meaning it is prohibited without an approved exception. Or the usage may be non-standard, meaning you are running something in a way that departs from the approved implementation.

Non-standard usage requests go to the PPSM CCB. Banned protocol exceptions are staffed through the Defense Security and Cybersecurity Authorization Working Group, and appeals go up to the DoD Information Security Risk Management Committee. The instruction also sets a fast lane: the CCB handles time-sensitive operational needs within 72 hours of receipt. Read that narrowly. It is scoped to operational urgency, not to a deployment date that slipped. Because these routing paths and timelines get updated, confirm the current process with your component PPSM office before you build a schedule around it.

An approved exception is a finite thing. It has scope, an expiration, and usually conditions. Track it the way you track a POA&M milestone, because an expired exception is a finding waiting for the next assessment window.

How it shows up in an assessment

Assessors do not take the PPS list at face value. The sequence I see, nearly every time:

• Ask for the registered PPS list for the system.
• Lay it next to the authorization boundary diagram and check that every crossing on the diagram appears on the list.
• Ask for the running firewall or ACL configuration and compare rule by rule.
• Spot-check two or three services against the CAL entry to see whether the required mitigations are in place.
• Check whether any exception cited is current, in scope, and signed.

Anything in the configuration that is not in the registration is an undeclared PPS, and it usually writes up under CM-7 rather than under PPSM, which catches people off guard. Anything in the registration that is not in the configuration is a documentation defect, which is cheaper but still a finding. Nobody has ever thanked me for finding an undocumented port, which is roughly how I know it was worth finding.

Why registrations get kicked back

The reasons repeat. Before you submit, check every one of these:

• Justification is generic, so the reviewer cannot tell what mission capability breaks without it.
• Any-to-any source or destination instead of named hosts or defined ranges.
• The boundary is mislabeled, usually calling an internet-facing flow an enclave-to-enclave flow.
• No encryption or authentication described for traffic that clearly needs both.
• The CAL entry requires mitigations the registration does not mention.
• The protocol is banned or non-standard and no exception request accompanies the submission.
• The PPS list does not match the boundary diagram or the software inventory.
• Version information is missing, so the vulnerability assessment cannot be applied.
• An expired exception is cited as if it were current.
• The submitting organization is not the one that owns the system of record.

Build the PPS list early, during implementation, not the week the package goes to the authorizing official. It costs an afternoon when the design is fresh and a month when it is not. If you want the PPS list sitting in sequence with the rest of your Step 3 and Step 4 evidence, my RMF Checklist lays out the order I work in.