# Aerospace & Defense Aerospace software is not regular software. When code runs on a flight-critical system — fly-by-wire controls, engine FADEC, collision avoidance, autoland — a defect is not a support ticket. It is ... ## Aerospace & Defense Software: DO-178C, ITAR & MRO Systems Flight-critical software to DAL A standards. ITAR-compliant development environments with DFARS 252.204-7012 and CMMC 2.0 Level 2 controls. Custom MRO platforms that replace $500K+ COTS implementations. FreedomDev builds safety-critical, export-controlled, and mission-critical software for aerospace primes, defense subcontractors, and MRO providers — with 20+ years delivering regulated software systems. --- ## Key Stats - **$90B+**: global aerospace MRO market, projected to exceed $115B by 2030 - **110**: NIST SP 800-171 controls required for CMMC 2.0 Level 2 certification - **1,900+**: suppliers in a single F-35 program across 47 states - **10x–25x**: cost multiplier for DAL A certification vs. DAL D - **$1.3M**: maximum ITAR penalty per violation, plus up to 20 years imprisonment - **30–40%**: reduction in unscheduled AOG events with condition-based maintenance --- ## Frequently Asked Questions ### What is the difference between DAL A, B, C, D, and E in DO-178C, and how do we determine which level applies? DO-178C Design Assurance Levels are determined by the failure condition severity of the system the software controls, as assessed through the system safety process defined in ARP 4761. DAL A applies to catastrophic failure conditions — those that could prevent continued safe flight and landing, resulting in loss of aircraft. DAL B applies to hazardous/severe-major conditions that reduce aircraft or crew capability to cope with adverse conditions. DAL C covers major failure conditions with significant impact on safety margins or crew workload. DAL D handles minor conditions noticeable to the crew but within aircraft capability. DAL E covers no-effect conditions requiring no DO-178C objectives. The critical determination happens at the system level (ARP 4754A), not the software level — your systems safety engineers and DERs assess failure conditions for each function, and that assessment flows down to the software implementing those functions. Getting this assessment wrong has massive cost implications: DAL A requires MC/DC structural coverage and independent verification, costing 10x-25x more than DAL D. FreedomDev works with your systems engineering team and DERs early in the program to ensure correct DAL assignment, and we apply architectural partitioning (ARINC 653 for IMA platforms) to isolate mixed-criticality functions so that only the truly catastrophic functions bear DAL A costs. ### How do we make our software development environment ITAR compliant? ITAR compliance for software development requires satisfying four interconnected requirements under 22 CFR 120-130. First, personnel: every individual with access to ITAR-controlled technical data — developers, testers, systems engineers, IT administrators, even janitorial staff with physical access to development areas — must be verified as a U.S. person (citizen or permanent resident). Second, infrastructure: development servers, version control, CI/CD pipelines, artifact repositories, and collaboration tools must reside on U.S.-sovereign infrastructure with no foreign national access at any operational level, including the cloud provider's operations and support staff. Third, a Technology Control Plan (TCP) that defines how controlled technical data is identified, marked, stored, transmitted, and disposed of within your organization. Fourth, facility coordination with DCSA (Defense Counterintelligence and Security Agency) for facility clearance if classified work is involved (DD Form 254). FreedomDev establishes compliant environments in 8-12 weeks, including infrastructure provisioning, access control implementation, TCP development, and personnel verification protocols. We also implement the technical controls that satisfy DFARS 252.204-7012 for Covered Defense Information, which frequently overlaps with ITAR data in defense programs. ### What does CMMC 2.0 Level 2 require and how does it affect our software systems? CMMC 2.0 Level 2 requires full implementation of all 110 security controls in NIST SP 800-171 Revision 2 across every system that stores, processes, or transmits Controlled Unclassified Information (CUI). This includes your software development environment, build servers, test infrastructure, deployment pipelines, production systems, backup systems, and any endpoint that can access CUI. The 110 controls span 14 families: access control, awareness and training, audit and accountability, configuration management, identification and authentication, incident response, maintenance, media protection, personnel security, physical protection, risk assessment, security assessment, system and communications protection, and system and information integrity. Level 2 requires third-party assessment by a CMMC Third-Party Assessment Organization (C3PAO) — self-attestation is no longer sufficient. FreedomDev builds systems with these controls as architectural requirements from the start. Encryption uses FIPS 140-2 validated modules for CUI in transit and at rest. Audit logging captures all CUI access events with tamper-evident storage. Multi-factor authentication is enforced for all CUI system access. Our deliverables include the System Security Plan (SSP) and technical evidence packages that C3PAO assessors require. ### How do we modernize our legacy MRO system without disrupting flight operations? The same way you overhaul an engine — in stages with a serviceable spare available at every step. Ripping out a legacy MRO system (SAP PM, IFS, Ramco, or custom mainframe) and replacing it in a single cutover is a $5M-$20M multi-year program with catastrophic risk if the new system fails on go-live day. FreedomDev takes an incremental modernization approach. Phase 1: build a modern data integration layer that reads from your legacy system in real time via APIs, database replication, or ETL pipelines. This gives you a live mirror of your legacy data in a modern data model without touching the legacy system. Phase 2: build new capabilities on top of the modern data layer — digital work orders on tablets for mechanics, predictive maintenance analytics from sensor data, real-time parts visibility across warehouses — while the legacy system continues to serve as the system of record. Phase 3: migrate transactional workflows one at a time from the legacy system to the new platform, with dual-run validation to confirm data integrity at each step. Phase 4: decommission the legacy system only after all workflows have been migrated and validated. This approach keeps your MRO operation running continuously with zero disruption to aircraft availability, which is the only metric that matters in aviation maintenance. ### What are SBOM requirements for defense software and how do we comply? Executive Order 14028 and subsequent NIST and CISA guidance require Software Bill of Materials (SBOM) for all software sold to the federal government, including defense systems. An SBOM is a machine-readable inventory of every software component in a deliverable system: commercial libraries, open-source packages, firmware modules, third-party SDKs, and any other code not written by your development team. The SBOM must be in SPDX or CycloneDX format and include component name, version, supplier, cryptographic hash, and license information. For defense contractors, compliance has two dimensions. First, generation: instrumenting your build pipeline to produce SBOMs automatically for every release. Modern build tools (Maven, Gradle, npm, pip, cargo) can generate dependency manifests, and tools like Syft, Trivy, or FOSSA convert these into SPDX/CycloneDX format. Second, continuous monitoring: each component in your SBOM must be continuously checked against the National Vulnerability Database (NVD) and CISA Known Exploited Vulnerabilities (KEV) catalog, with alerts when new CVEs affect your deployed software. FreedomDev builds SBOM generation into CI/CD pipelines and integrates continuous vulnerability monitoring with your security operations workflow. ### How do AS9100D and Nadcap requirements affect custom aerospace software? AS9100D is the aerospace quality management standard based on ISO 9001:2015 with additional requirements for product safety, counterfeit part prevention, configuration management, risk management, and special process controls. If your organization holds or pursues AS9100D certification, your custom software must support — not hinder — these quality processes. Concretely, this means document control with revision management and electronic approval workflows that satisfy clause 7.5 (documented information). Nonconformance and CAPA management with root cause analysis satisfying clause 8.7 (control of nonconforming outputs) and 10.2 (corrective action). First article inspection (FAI) per AS9102 with digital form generation. Supplier quality management with approved supplier lists and incoming inspection records per clause 8.4. Configuration management per clause 8.1.2, which in aerospace requires tracking every change to product definition, production process, and inspection criteria. For Nadcap-accredited special processes (heat treating, welding, NDT, chemical processing, surface enhancement), PRI auditors require objective evidence that process parameters were controlled and recorded in real time — not entered after the fact. FreedomDev builds quality management systems that digitize these processes with real-time data capture, automated workflow routing, and audit-ready reporting that satisfies both AS9100D registrar audits and Nadcap task group assessments. --- ## DO-178C Certified Software Development Process Aerospace software is not regular software. When code runs on a flight-critical system — fly-by-wire controls, engine FADEC, collision avoidance, autoland — a defect is not a support ticket. It is a potential loss of aircraft and life. DO-178C (Software Considerations in Airborne Systems and Equipment Certification) exists because the FAA and EASA recognized that traditional software development practices are insufficient for systems where failure consequences are catastrophic. The standard defines five Design Assurance Levels (DAL A through DAL E) based on the severity of failure conditions. DAL A — catastrophic failure conditions that could cause loss of aircraft — requires Modified Condition/Decision Coverage (MC/DC) testing, 100% structural code coverage, independence between verification and development activities, and full traceability from system requirements through software requirements, architecture, source code, and executable object code. DAL B applies to hazardous failure conditions. DAL C covers major failure conditions. DAL D handles minor failures. DAL E applies to no-effect conditions and requires no specific DO-178C objectives. The cost difference between assurance levels is staggering. Industry data consistently shows that DAL A certification costs 10x to 25x more than DAL D for equivalent functionality, driven almost entirely by the verification, traceability, and documentation requirements — not the code itself. A DAL A project may spend 60-70% of total effort on verification activities alone. This is why accurate failure hazard assessment at the system level (per ARP 4761) is so critical: misclassifying a component as DAL A when it should be DAL C can add millions to development costs and years to the schedule. FreedomDev works with systems engineers and DERs (Designated Engineering Representatives) to ensure software levels are correctly assigned before development begins, not discovered during the Stage of Involvement reviews with FAA certification authorities. ITAR (International Traffic in Arms Regulations) and EAR (Export Administration Regulations) add another layer of complexity that most commercial software firms do not understand and are not equipped to handle. ITAR controls defense articles and defense services on the United States Munitions List (USML). EAR controls dual-use items on the Commerce Control List (CCL). If your software touches anything on the USML — missile guidance algorithms, satellite command-and-control systems, cryptographic modules for classified communications, electronic warfare signal processing — every person who accesses the source code, design documents, or technical data must be a U.S. person as defined under 22 CFR 120.62. Development environments must be physically and logically segregated. Cloud infrastructure must reside on U.S.-sovereign servers with no foreign national access. Violations carry penalties up to $1.3 million per violation and 20 years imprisonment. This is not compliance theater — it is export control law enforced by the Directorate of Defense Trade Controls (DDTC) and the Bureau of Industry and Security (BIS). The aerospace MRO (Maintenance, Repair, and Overhaul) market exceeds $90 billion globally and is projected to surpass $115 billion by 2030, driven by fleet aging, increased flight hours, and the transition to performance-based logistics (PBL) contracts. Yet the MRO software landscape is dominated by legacy systems — SAP MRO, IFS Applications, Ramco Aviation, and custom-built mainframe systems from the 1990s — that were designed for paper-based work order flows and do not support modern predictive maintenance, digital twin integration, or real-time parts visibility across multi-tier supply chains. Defense MRO adds DFARS requirements: DFARS 252.204-7012 mandates adequate security for Covered Defense Information (CDI) on contractor systems, and CMMC 2.0 Level 2 certification — which requires compliance with all 110 controls in NIST SP 800-171 — is now required for contractors handling Controlled Unclassified Information (CUI). FreedomDev builds custom MRO platforms that meet both operational and compliance requirements from day one. Supply chain visibility is the defining challenge of 2020s defense contracting. The defense industrial base is a multi-tier ecosystem where Lockheed Martin, Boeing, Raytheon (RTX), L3Harris, and Northrop Grumman sit at the top as prime contractors, sourcing from thousands of Tier 2 and Tier 3 subcontractors who in turn source from Tier 4 and Tier 5 component suppliers. A single F-35 Lightning II program involves over 1,900 suppliers across 47 states and multiple allied nations. When a Tier 3 supplier in Ohio cannot deliver a machined titanium bracket on schedule, the ripple effect reaches the final assembly line in Fort Worth months later — but the prime often does not know about the delay until it is too late to mitigate. The DoD's push for Software Bill of Materials (SBOM) requirements, codified in Executive Order 14028 and subsequent NIST guidance, adds software supply chain transparency to this physical supply chain challenge. Every software component — commercial libraries, open-source dependencies, firmware modules — must be documented, tracked for known vulnerabilities (CVEs), and reported to acquiring programs. FreedomDev builds the supply chain visibility and SBOM management platforms that defense contractors need to meet these requirements. --- ## Technologies - DO-178C - DO-254 - DO-330 - ARP 4754A - ARP 4761 - ARINC 653 - ARINC 661 - MIL-STD-498 - MIL-STD-882E - FACE (Future Airborne Capability Environment) - SOSA (Sensor Open Systems Architecture) - MOSA (Modular Open Systems Approach) - SBOM (SPDX / CycloneDX) - NIST SP 800-171 - FIPS 140-2 - SAP MRO - IFS Applications - ACARS - OPC-UA - REST APIs - PostgreSQL - .NET - LDAP/Active Directory --- **Canonical URL**: https://freedomdev.com/industries/aerospace-defense _Last updated: 2026-05-14_