RMFInsider

The distinction is scope, and it decides whether you owe an authorization package. Platform IT, in the DoD sense carried forward from DoDI 8500.01, is information technology, hardware and software both, that is physically part of, dedicated to, or essential in real time to the mission performance of a special purpose system. A single embedded controller, a sensor card, a proprietary board inside a launcher: that is PIT, and it is evaluated as a component of the platform rather than receiving its own authorization decision. A PIT system is an interconnected collection of that PIT, with a defined boundary, an identifiable mission, and something that looks like an operating environment. A PIT system goes through RMF and gets its own authorization decision. Treating a PIT system as if it were loose PIT is the error that leaves programs without an authorization for years.

Where the definitions come from, and the version caveat

The PIT definition that everyone quotes traces to DoDI 8500.01 and is carried in CNSSI 4009: IT, both hardware and software, that is physically part of, dedicated to, or essential in real time to the mission performance of special purpose systems. DoDI 8510.01 is what historically told you which flavor of platform IT enters RMF and which is handled below the system level.

Here is the caveat I would rather give you than a confident wrong answer. DoDI 8510.01 has been revised, and the current text frames the below-the-system-level case as “Assess Only,” describing technologies such as components, hardware, software, and external services that do not require an ATO but still complete assessment procedures. Components have also issued their own platform IT and operational technology guidance, and the terminology is not uniform across the Services. The underlying engineering test has stayed stable for a decade; the labels have not. Read the current instruction, which I walk through in my breakdown of DoDI 8510.01, alongside your component’s platform IT policy, and let your authorizing official’s office settle the label.

The decision test that actually resolves it

Strip away the vocabulary and ask these questions about the thing in front of you. A yes on the first two and on at least two of the rest, in my experience, means you are looking at a PIT system:

• Does it have a boundary you can draw, with components inside it that you control and defined interfaces out?
• Does it have a mission or function of its own, distinct from being one part in a larger platform?
• Are there two or more computing components talking to each other over a network or bus you own?
• Does it run a general purpose operating system anywhere inside it, even one embedded appliance running Linux or Windows?
• Does it store, process, or transmit data that has a confidentiality, integrity, or availability impact worth categorizing?
• Does it have users, accounts, or roles that someone has to administer?
• Does it connect to anything outside the platform, including a maintenance laptop, a vendor remote support path, or a network drop?
• Could it be patched, configured, and scanned independently of the platform it sits in?

If the answer to the boundary question is no, because the item is a single product that exists only as a part inside somebody else’s boundary, you are looking at PIT. It gets inherited or assessed with the host, and the host’s package describes it in the inventory and the design.

Examples, sorted the way I sort them

The categories that draw the longest arguments in program reviews:

• Weapons systems: the fire control computer network aboard a ship or an aircraft mission system is typically a PIT system. A single seeker head inside a munition is PIT.
• Medical devices: an infusion pump on its own is PIT. The hospital’s networked infusion pump management server plus its pumps plus its wireless segment is a PIT system, and it is usually the network that forces the answer.
• Industrial control systems and SCADA: a single programmable logic controller is PIT. The supervisory control network with its human machine interfaces, historian, and engineering workstation is a PIT system.
• Training simulators: full mission simulators are generally PIT systems. They have servers, instructor stations, accounts, and network connections, which is every yes on the list above.
• HVAC and building control systems: a standalone thermostat is PIT. A facility-related control system with a building automation front end, a network of controllers, and a remote support path is a PIT system, and this is the category that hides in facilities budgets rather than IT budgets.

The pattern is consistent. Interconnection plus administration plus a boundary you can draw pushes you to PIT system. A sealed part inside somebody else’s product does not.

Who authorizes it

Authorization for a PIT system follows the same chain as any other DoD system: a designated authorizing official, appointed through your component, makes the decision on the package. What differs in practice is which authorizing official. Platform IT often lives with a program executive office, a systems command, or a facilities organization rather than with the network owner, so the authorizing official for the PIT system is frequently not the one who holds the ATO for the base network it plugs into.

Sort that out early and in writing. I have watched a control system sit unauthorized for nine months because the installation’s authorizing official assumed the program office owned it, and the program office assumed the installation did. Nothing was in dispute. Nobody had been told they owned it.

How the assessment differs

The controls are the same catalog. The testing is where platform IT diverges, and the honest answer is that a competent assessor adapts rather than skips.

Scanning is the first difference. You often cannot run a credentialed scan against an embedded controller, and in some cases you cannot scan it at all while the platform is operational. That drives you to configuration review, vendor attestation, and testing on a representative bench rather than on the live platform. Document why, in the control assessment, rather than leaving a blank result.

Availability drives the second difference. Patching a weapons system or a building control system usually requires a maintenance window tied to the platform’s own schedule, which means SI-2 flaw remediation timelines need a documented, approved deviation rather than silent noncompliance. Categorize honestly, too. Availability is frequently the driving impact level on a PIT system, which changes the baseline more than people expect, and my walkthrough of Step 1 categorization under FIPS 199 covers how that plays out.

Third, overlays and tailoring carry real weight here. Compensating controls around physical access, isolation, and monitoring often do the work that a technical control cannot do on an embedded device. Write the rationale in the implementation statement, not in an email.

PIT interconnections

A PIT system rarely stands alone, and the connections are where assessors spend their time. Three kinds come up.

The platform-internal connection, meaning PIT talking to PIT inside the boundary, belongs in your design documentation and your boundary diagram, not in a separate agreement. The connection from the PIT system to an enterprise network is the one that needs a formal agreement and a connection approval, because two authorizing officials now share risk. Vendor remote maintenance paths are the third, and they are the ones nobody volunteers during a walkthrough. A cellular modem for remote support is an external connection whether or not it appears on the diagram.

For the enterprise-facing connection, you are in interconnection security agreement and CA-3 territory, and the ports and protocols crossing that boundary have to be declared through the PPSM process like any other traffic.

The determination memo nobody wrote

This is the trap, and it is procedural rather than technical. Somebody has to write down whether a given thing is PIT or a PIT system, on what basis, and who the authorizing official is. That determination is usually a short memo signed by the authorizing official or the component’s cybersecurity office, sometimes handled as part of a registration decision.

Without it, the system sits in limbo. The program cannot start Step 1 because it has no confirmed authorization path. The network owner will not grant a connection without an authorization decision. The assessor cannot scope an assessment without a boundary. Everyone waits for a decision that no one has been asked to make, and the next thing that happens is an operational need date and a scramble.

Write the memo yourself as an ISSO if you have to. A one-page draft with the decision test answered, the proposed boundary, the proposed authorizing official, and a signature block is far easier for somebody to sign than a request to make a determination from scratch. That is the single highest-leverage page I have written on a platform IT program.

The evidence a PIT system package needs

Beyond the standard artifact set, a PIT system package is expected to carry these, and every assessor I have worked with has asked for at least half of them:

• The PIT or PIT system determination, signed, naming the authorizing official.
• A boundary description and diagram that shows the platform, the PIT inside it, and every external interface including maintenance paths.
• A component inventory that covers embedded devices, firmware versions, and vendor-supplied software, not just servers and workstations.
• The categorization decision with its rationale, and the overlays applied.
• The rationale for any control assessed by means other than scanning, including bench testing and vendor attestation.
• Approved deviations from standard patch timelines, tied to the platform maintenance schedule.
• Agreements and connection approvals for each external connection, including vendor remote support.
• Declared ports, protocols, and services for traffic crossing the boundary.
• The configuration baseline for the platform, and the change process that keeps it current.
• Physical and environmental control evidence, which carries more weight here than on a server in a data center.

If your PIT system has no authorization path yet, start with the determination and the boundary and build the rest in sequence. My RMF Checklist lays out that order, and it works the same for a simulator or a chiller plant as it does for an enclave.