ITAM for Aviation and Airlines: What TSA’s Directive Actually Requires
Ask an aviation IT leader what “safety-critical compliance” means, and the answer is almost always airworthiness. DO-178C for software, DO-254 for hardware, FAA type certification, a world governed by aircraft manufacturers and avionics suppliers, with no role for enterprise IT asset management (ITAM). That answer is correct. It is also not the compliance question TSA has been asking airlines and airports since March 2023.
This piece is about the ground IT and OT layer TSA designates as critical cyber systems: the servers, network gear, endpoints, and applications whose compromise can cascade into an operational disruption. ITAM for aviation and airlines, in that sense, means a reconciled hardware and software inventory with version, patch, ownership, and lifecycle evidence an auditor can read. It is not avionics certification, and it is not aircraft-parts MRO tracking.
Two Different Things Called Safety-Critical, and Only One Involves ITAM
Airworthiness compliance is a certified domain. DO-178C and DO-254, plus FAA and EASA type certification, sit with OEMs, avionics suppliers, and certification offices. Enterprise ITAM software does not certify flight software, does not hold airworthiness records, and should never claim that role. That line stays fixed throughout this article.
TSA’s 2023 cybersecurity requirements for airport and aircraft operators created a second, legitimate meaning of safety-critical. Operators must identify critical cyber systems and apply security measures to the ground-based IT and OT that support airport and airline operations. A security incident on that layer can become an operational incident: delayed clearances, grounded flights, degraded passenger processing, or blocked cargo and maintenance workflows.
A third label often collides in search: aviation “asset management” as aircraft parts, tooling, and life-limited components in MRO systems such as AMOS, TRAX, or Ramco. That discipline is mature and necessary. It is not ITAM for corporate or station IT estates. If your team tracks line-replaceable units and airworthiness directives, you are in MRO. If your team must prove which OS build, driver pack, and firmware revision sits on a named critical cyber system, you are in ITAM.
What the TSA Directive Requires, and What It Assumes You Already Know
TSA’s direction for covered airport and aircraft operators centers on identifying critical cyber systems and applying four measures against them: network segmentation, access control, continuous monitoring, and timely, risk-based application of security patches and updates for operating systems, applications, drivers, and firmware. Directive text is amended over time. Confirm current language, scope, and enforcement with your legal, compliance, and security counsel before treating any summary as binding advice.
Read the four measures as inventory problems first.
Segmentation only works if you know which assets sit on which segment, and which of those assets support a named critical cyber system. Access control needs the same identity of systems and endpoints, not a stale diagram. Continuous monitoring needs a stable asset list so sensors and logs map to real devices. Patch management, in the directive’s own wording, reaches OS, applications, drivers, and firmware. None of that work is executable without current answers to three questions: what is the system, what is installed on it and at what version or patch level, and who owns it.
The directive names outcomes. It does not spell out “maintain a live IT asset inventory.” The inventory work is assumed. When that assumption fails, segmentation policies become aspirational, patch cadences miss the vulnerable build still in production, and implementation-plan reviews turn into spreadsheet rebuilds.
CISOs and GRC leads feel this as evidence risk. ITAM managers feel it as the night-before-audit scramble. Both are looking at the same gap.
Shield your organization from audit exposure with Trusted Runtime Truth.
What Happens Without That Inventory: the FAA’s Own Record
Public audit findings on FAA systems are useful here as industry evidence, not as a critique of the agency or as any claim of commercial relationship. They show what “we cannot precisely state what this critical system is and what state it is in” looks like under independent review.
In September 2024, the U.S. Government Accountability Office published GAO-24-107001 reviewing FAA air traffic control systems. Among 138 systems reviewed, 51 (37%) were rated unsustainable, and 105 of 138 were unsustainable or potentially unsustainable. Findings cited outdated hardware, spare-parts pressure, and critical systems without active modernization investment. That is a hardware lifecycle and sustainability story as much as a cybersecurity story.
DOT Office of Inspector General follow-on work on high-impact National Airspace System systems found adherence to outdated NIST security control baselines, inadequate documentation, and failures to track and mitigate known cyber vulnerabilities. The failure mode is tracking and documentation discipline, not a single dramatic breach.
For airlines, airports, MRO IT, and ground handlers, the parallel is direct. TSA expects operators to segment, control, monitor, and patch named critical cyber systems. An operator that cannot produce a current hardware and software inventory for those systems is arguing from the same weak position the audits describe: incomplete knowledge of estate state. Board and civil-penalty exposure for security-directive noncompliance makes that a CISO and GRC problem, not only an ITAM backlog item.
The Trap: Treating This as a Point-in-Time Audit Response
A one-time inventory built for a TSA implementation-plan review answers one calendar date. The next day, a station server is swapped, a vendor appliance is added on a shared segment, a firmware update ships on a firewall pair, or a new application build lands on a gate-system host. The export that looked complete in the review package is already wrong.
The next review or internal audit then restarts the scramble: pull CMDBs that were never reconciled, merge spreadsheets from network and desktop teams, guess ownership, and hope patch reports still match install reality. Point-in-time ITAM does not support risk-based patching “in a timely manner,” because timely assumes you still know which hosts run the vulnerable version after the last change window.
ITAM managers already know this pattern from software license audits. Aviation’s version swaps the software publisher for a regulator-shaped review cycle. The fix is the same shape: discovery that refreshes the record on a schedule, reconciliation into one asset and CI record, and history that shows what changed between reviews.
Continuous Asset Visibility Is What Makes the TSA Measures Real
Practical ITAM for aviation ground estates is a continuously reconciled hardware and software inventory with lifecycle state, version and patch detail, license position where software entitlements apply, and an audit trail. Multi-source discovery, using agent-based, agentless, and API-fed cloud or hypervisor sources, feeds that inventory so segmentation, access, monitoring, and patch decisions use a current picture rather than a quarterly CSV.
Virima ITAM is built for that corporate and station IT problem set. Agent-based and agentless discovery populate hardware and software inventory, including OS and install fingerprinting useful for patch and version questions. Records carry lifecycle status from request through production to decommission. Software license position can be compared to discovered installs. A CMDB layer holds configuration relationships and change history so ownership and dependency context sit with the asset, not in a side spreadsheet. High-frequency discovery cycles refresh the estate on a schedule; this is not passive real-time event streaming, and it should not be positioned as airworthiness, dispatch, or flight-control tooling.
The outcome, in auditor language: you can show the named critical cyber systems in your implementation plan, the supporting servers and network devices, the OS and application versions those hosts run, and the owner of each record. That is compliance evidence for ground IT and OT. It is not a substitute for MRO airworthiness systems, and it is not a claim about FAA-certified avionics.
Shared aviation infrastructure providers may already expose configuration visibility for the common-use estate they operate. That does not replace each airline’s or airport’s duty to inventory the systems it owns and designates as critical. Internal ITAM still owns the private estate.
Where to Start: Scope the Inventory Against TSA’s Critical Cyber Systems
Start narrow. Breadth without a critical-system boundary recreates the spreadsheet problem at larger scale.
- Named critical cyber systems in your current TSA implementation plan, plus every server, workstation, appliance, and network device that supports them.
- OS, application, driver, and firmware versions on those systems, matching the fields patch management actually consumes.
- Network segments and membership, so segmentation policy maps to discovered assets instead of design diagrams alone.
- Ownership on every in-scope record. An unowned component of a critical cyber system is a governance gap before it is a ticket.
Use a structured IT asset management checklist to lock discovery scope, tagging, and review cadence. Expand only after the critical set reconciles cleanly. Pair inventory health with your IT risk register so unsustainable hardware, missing owners, and unpatched builds show up as tracked risks, not slide footnotes.
Closing the Compliance Gap on the Ground Estate
Safety-critical compliance in aviation IT is larger than the certified world of avionics and airworthiness. TSA already regulates a second, ground-based layer of critical cyber systems. That layer cannot be segmented, monitored, or patched on a risk-based schedule unless you know what is running on it, at what version, and under whose ownership. That is an asset-inventory problem with an audit trail. It is solvable with discovery-sourced ITAM and CMDB practice before the next review forces another rebuild.
ITAM leads get a defensible record. CISOs get evidence that the four measures sit on known systems. GRC and audit leaders get a paper trail that survives a second look.
Book a personalized demo to see how Virima correlates live hardware and software inventory with the lifecycle and ownership detail audit reviews demand.
Frequently Asked Questions
Is IT asset management the same as tracking aircraft parts and MRO inventory?
No. MRO asset systems track aircraft parts, tooling, and maintenance records against airworthiness rules. ITAM tracks corporate and station IT and OT hardware and software: servers, endpoints, network devices, OS builds, applications, drivers, firmware, licenses, owners, and lifecycle state. Both matter. They answer different regulators and different questions.
What does the TSA aviation cybersecurity directive require operators to track?
Covered operators must identify critical cyber systems and apply segmentation, access control, monitoring, and risk-based patching of operating systems, applications, drivers, and firmware. Those measures assume a current inventory of the systems and what is installed on them. Confirm the latest directive text with counsel; public summaries are not legal advice.
What counts as a critical cyber system under TSA aviation security direction?
In practice it is the ground IT and OT an operator designates in its implementation plan: systems whose compromise or failure can disrupt airport or airline operations. Exact designations are operator-specific. ITAM’s job is to inventory the supporting hardware and software once those names exist, not to redefine the regulatory list.
Why did GAO find so many FAA air traffic control systems unsustainable?
GAO-24-107001 reported that 51 of 138 systems (37%) were unsustainable, with 105 of 138 unsustainable or potentially unsustainable, citing outdated hardware, parts risk, and missing modernization on some critical systems. The lesson for operators is lifecycle and inventory discipline on high-impact estates, not a claim about any vendor relationship with FAA.
How do airlines and airports prove IT asset compliance in a TSA-style review?
Produce the named critical cyber systems, the supporting assets, current OS and software versions, segment membership, owners, and patch or lifecycle status from a reconciled inventory with history, not a one-off spreadsheet. Discovery-sourced ITAM and CMDB records are built for that evidence path on ground IT estates.
