Introduction
A team new to defense and aerospace embedded work usually discovers two compliance dimensions at once, and conflates them at first. DO-178C compliant software development governs how airborne software is designed, implemented, and verified, an engineering process standard. Export control classification, ITAR or EAR depending on the program, governs who is allowed to touch the code, where the data can live, and how it can be shared, a legal and organizational constraint layered on top of the engineering process. Programs that treat these as one combined checklist item tend to discover the gap between them at the worst possible time, usually during an audit or a staffing change.
In short: ITAR and export control considerations for defense embedded software development shape team staffing, data handling, and IP protection from day one of a program, while DO-178C and DO-254 shape the engineering process itself, and a compliant development environment has to satisfy both simultaneously, not as separate phases.
ITAR vs. EAR: Which Applies and When
The International Traffic in Arms Regulations (ITAR) govern defense articles and services on the United States Munitions List, while the Export Administration Regulations (EAR) cover a broader category of dual-use items with both civilian and military applications. Which regime, or regimes, apply to a given program depends on the specific technology, the end customer, and the countries involved, and the classification can differ for what looks like a similar deliverable on two different programs. Getting this classification wrong in either direction carries real consequences: over-classifying adds unnecessary cost and staffing friction, while under-classifying creates genuine legal exposure. This determination needs to happen at program kickoff, with input from the customer's own export-control compliance function, not assumed by the engineering team based on general familiarity with defense work.
How Export Classification Affects Team Staffing and Location
Once a program's export classification is established, it directly constrains who can work on it. ITAR-controlled technical data generally cannot be shared with non-U.S. persons without a specific license, which affects staffing decisions for any program with international team members, a common reality for a globally distributed engineering organization. Practical mitigations include walling off ITAR-controlled work streams to a specifically cleared subset of the team, physically and logically isolating the development environment and data from the broader organization's infrastructure, and building the program's staffing plan around the classification from the proposal stage rather than discovering a staffing conflict after the team is already assigned.
Data Handling and IP-Protection Implications
Export-controlled technical data carries handling requirements that go beyond a typical NDA: where the data can be stored, which countries' cloud infrastructure it can transit, and how access is logged and audited all become contractual and sometimes legal requirements rather than internal best practice. This intersects directly with intellectual property protection, because the same isolation measures that satisfy export-control data handling requirements, segregated repositories, restricted access lists, controlled build environments, also happen to be exactly the controls a customer wants in place to protect their own proprietary design IP. Programs that build this infrastructure once, to satisfy both requirements simultaneously, avoid duplicating the same access-control engineering effort twice.
DO-178C Software Development and DO-254 Compliance: What the Engineering Process Requires
DO-178C software development defines Design Assurance Levels (DAL A through E) based on the safety consequence of a software failure, with DAL A, the level applied to software whose failure could cause a catastrophic event, demanding the most rigorous requirements traceability, structural coverage analysis, and independent verification. DO-254 compliance applies the equivalent discipline to complex airborne electronic hardware, FPGAs and custom ASICs in particular, requiring a documented hardware design lifecycle with equivalent rigor to DO-178C's software lifecycle. Programs requiring DAL A certifiable artifacts need requirements-based test coverage, verifiable traceability from requirement through implementation to test case, and configuration management discipline sufficient to reconstruct exactly what was built and verified at any point in the program, a level of process rigor that has to be designed into the development environment from the start rather than retrofitted for a certification audit.
Common Compliance Mistakes Engineering Teams Make Early
Teams new to this combination of requirements make a consistent set of early mistakes: assuming export classification is a one-time determination rather than something that needs revisiting as a program's scope changes; treating DO-178C traceability as a documentation exercise performed after development rather than a live artifact maintained throughout it; and underestimating how much of the development toolchain itself, compilers, static analysis tools, configuration management systems, needs to be qualified or at least documented as part of the certification evidence package. Each of these mistakes is cheap to avoid early and expensive to fix once a program is well underway.
What a Compliant Development Environment Looks Like in Practice
A development environment built for this combination looks different from a typical commercial embedded software setup: access-controlled repositories segregated by export classification, a documented and where necessary qualified toolchain, requirements-management tooling that maintains live traceability rather than a point-in-time spreadsheet, and a configuration management process rigorous enough to answer exactly what changed, when, and why for any build a certification authority might ask about. This infrastructure represents real upfront investment, but it is far cheaper to build once at program start than to reconstruct retroactively when a certification review asks for evidence the team didn't know it needed to preserve.
How Does Embien Support Defense Electronics Development?
How does Embien support defense electronics development under this combination of requirements? Our teams work within the DO-178C and DO-254 process discipline required up to Design Assurance Level A, delivering certifiable hardware and software artifacts alongside MIL-STD and CEMILAC-aligned engineering practices. On export control specifically, we're direct about where we stand: Embien is not itself ITAR-registered, but we maintain processes designed to operate within the framework required for ITAR-controlled information and components when a program calls for it, and we'd rather a prospective partner know that distinction upfront than discover it mid-program.
Questions to Ask a Prospective Engineering Partner About Their Compliance Posture
Before committing a mission-critical program to an engineering partner, a program manager should ask specifically: what Design Assurance Levels has the team actually delivered certifiable artifacts against, not just worked adjacent to? Is the partner ITAR-registered, and if not, what specific processes do they have for handling ITAR-controlled data and components? How is export-controlled work segregated from the rest of the organization's staffing and infrastructure? And can the partner produce a real example of a traceability matrix or configuration management record from a past program, not just a description of their process? A partner that answers these specifically, including admitting where their qualification stops short, is a safer bet than one that answers only in generalities.
Embien's Capabilities
Embien's mission-critical engineering practice is built around DO-178C and DO-254 process discipline up to Design Assurance Level A, MIL-STD-461/810 environmental qualification, and CEMILAC-aligned certification support, backed by defined processes for handling export-controlled technical data and components even though Embien itself is not ITAR-registered. Our engineering teams build the access control, traceability, and configuration management infrastructure a compliant program needs from the first architecture review.
To discuss compliance posture and process fit for a DO-178C, DO-254, or export-controlled defense software program, reach out to Embien's mission-critical engineering team.