How do you know when a software tool needs qualification?

Certification teams often make one of two expensive assumptions: every tool must be qualified, or a commercial tool never does. Both miss the decision that matters—what certification credit the project takes from the tool’s output.

Short answer: Under DO-178C, a tool generally needs qualification when the project uses it to eliminate, reduce, or automate an applicable life-cycle process, does not otherwise verify the tool’s output, and a tool error could affect the software or the verification result. Qualification depends on intended use and project context—not the product name or a vendor claim.

By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed August 2026.

Tool use does not automatically mean tool qualification

A software tool is any computer program used to help develop, test, analyze, produce, or modify software or its documentation. That definition is broad. The qualification trigger is deliberately narrower.

RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, section 12.2 asks whether the project is relying on a tool in place of an applicable software life-cycle process or part of one. If the tool supports the work but every relied-on output receives the verification that the process otherwise requires, the tool is not earning certification credit. Its use alone does not create a qualification obligation.

That distinction is why a complete tool inventory matters, but a plan to qualify every item on it does not. For each tool, identify the functions the project will actually use, the outputs that support DO-178C objectives, and the checks that occur after those outputs are produced. The decision follows the reliance, not the size, cost, complexity, or commercial status of the tool.

FAA Order 8110.49A defines tool qualification as the process needed to obtain certification credit for a software tool within the context of a specific airborne system. That final phrase is important. Qualification is not a permanent label attached to a product, and the Federal Aviation Administration (FAA) does not generically certify a tool for every project.

A vendor’s qualification package can reduce the work needed to assemble evidence. It cannot decide your intended use, your operational environment, the credit your project takes, or whether the supplied data satisfy the objectives that apply to that use. “Qualified tool” is therefore incomplete shorthand unless the project can also state the version, configuration, functions, environment, and credit covered.

The decision starts with the credit you take

Use three questions in order.

1. Does the tool eliminate, reduce, or automate an applicable DO-178C process? If the project performs the complete process without relying on the tool’s result for certification credit, qualification is not triggered by that use.
2. Is the relied-on output otherwise verified? If another compliant activity independently confirms the output, that verification can provide the needed assurance. If the project accepts the output without that confirmation, continue.
3. Could a tool error matter within the intended use? The concern may be that the tool could introduce an error into airborne software or fail to detect an existing error. If neither can happen within the claimed use, qualification is not needed for that use.

All three parts belong in the decision record. “We use the tool” is not enough. Neither is “we do not independently verify its output.” Without the first question—what process is being reduced, eliminated, or automated—the analysis has not yet established that the project is taking certification credit through the tool.

Here is one concrete example. A test-results analyzer reads execution logs and marks each test pass or fail. If an engineer independently evaluates the raw evidence and reaches the acceptance decision without relying on the analyzer’s status, the analyzer is not replacing that verification. If the project accepts the analyzer’s decision and removes that independent evaluation, an analyzer error could allow a failed result to appear acceptable; the qualification question is now real.

Independent verification is not a ceremonial second look. It must be capable of finding the relevant tool error and must satisfy the applicable verification objectives. A check that merely repeats the same tool logic, trusts the same corrupted input, or reviews only the format of the output may not provide the independence the argument assumes.

This creates a legitimate planning choice. A team can keep the downstream verification and avoid taking qualification credit, or it can qualify the relied-on tool use and reduce the recurring verification. The less expensive path depends on how often the tool is used, how difficult its outputs are to verify, and how much qualification evidence is available. The decision should be made from a documented process and evidence strategy—not from the purchase price of the tool.

This is also why tool decisions can materially affect the overall certification budget. AeroCert’s article on what DO-178C certification costs a small company places tool qualification beside software level, verification, planning, and review timing as a cost driver.

DO-330 sets the qualification rigor

Once the gateway conditions are met, DO-178C classifies the tool use according to the potential effect of a tool error. In plain language, the analysis distinguishes among a tool that could place an error into the airborne software, a verification tool whose result is used to reduce additional processes, and a verification tool that could fail to detect an error within the process it automates.

The classification and the software level supported by the tool determine a Tool Qualification Level (TQL). The TQL sets which objectives in RTCA DO-330, Software Tool Qualification Considerations, apply. It is not the software’s Design Assurance Level (DAL), and it is not a general quality rating for the tool.

FAA Advisory Circular (AC) 20-115D recognizes DO-178C as an acceptable means of compliance for airborne software and recognizes DO-330 for tool qualification. The AC states that DO-330 contains its own objectives, activities, and life-cycle data. It also explains that the TQL is determined from the tool’s use and potential impact together with the software level assigned by the system safety assessment.

The practical consequence is proportionality. Qualification evidence may include a Tool Qualification Plan, tool operational requirements, operational verification, configuration identification, quality-assurance records, and an accomplishment summary. The applicable TQL determines the depth of that evidence; the project should not invent one qualification package and apply it unchanged to every tool.

Tool operational requirements are the center of the argument. They state what the relied-on functions must do, the inputs and outputs involved, the environment in which the tool operates, the procedures and limitations on its use, and the behavior the project will verify. A narrow, accurate statement of intended use keeps the qualification aligned with the certification credit actually claimed.

DO-178B projects require separate treatment. DO-178B section 12.2 uses development-tool and verification-tool categories; DO-330 and the five TQLs arrived with DO-178C. FAA AC 20-115D provides transition guidance for legacy projects, but a team should not silently mix DO-178B terminology with a DO-178C qualification argument. Coordinate the governing software baseline and tool approach with the responsible certification authority.

Plan before the tool becomes infrastructure

The best time to decide whether qualification is needed is before the process depends on the tool. Reaching the first planning review with an unsupported assumption can affect verification procedures, budgets, supplier agreements, configuration controls, and the data the project must produce.

Build the analysis from a controlled tool inventory. For every tool that supports software life-cycle activities, record:

• the exact tool, version, source, and configuration;
• the functions and outputs the project intends to use;
• the DO-178C processes or objectives those outputs support;
• whether the outputs receive independent verification;
• what error the tool could introduce or fail to detect;
• the resulting qualification decision, criterion, and TQL when applicable;
• the operational environment, procedures, limitations, and responsible organization; and
• the qualification data available from the developer, supplier, or project.

The Plan for Software Aspects of Certification (PSAC) should make consequential tool decisions visible. It should identify the planned qualification approach and point to the qualification planning data where appropriate. If a decision is still open, record the issue, owner, and coordination path instead of implying the strategy is settled.

In the common four-review workflow, tool qualification needs should be visible by Stage of Involvement (SOI) 1, the planning review. Later reviews can then examine whether the approved approach is being executed and whether the qualification evidence supports the claimed use. What Happens When the FAA Looks at Your Software? SOI Reviews, Explained shows how those reviews follow the project from planning through final compliance.

Do not postpone the analysis until the tool is embedded in build, test, or analysis procedures. At that point, removing the credit may mean restoring verification the schedule no longer contains, while qualifying the tool may require data the vendor never planned to supply. That is the same avoidable pattern described in Why DO-178C Costs More When Compliance Starts Late.

Early coordination does not transfer responsibility to the FAA or a designee. The applicant remains responsible for performing the planned activities and producing the applicable life-cycle data. Coordination tests whether the proposed qualification strategy is understood and acceptable before the project treats it as an accomplished fact.

Keep qualification tied to the exact use

Qualification remains valid only inside the envelope supported by its evidence. A different tool version, host platform, configuration, plug-in, operating procedure, input range, output use, or certification credit can change that envelope. Each change needs impact analysis before the project assumes the previous qualification still applies.

The analysis should identify what changed, which tool operational requirements and qualification objectives are affected, whether prior verification remains valid, and what activity must be repeated. The answer may be no additional qualification work, limited reverification, broader requalification, restored independent output verification, or a change in the process. The conclusion must follow the evidence.

Known tool problem reports need the same discipline. Review whether an open problem can affect a relied-on function, whether the tool still meets its operational requirements, and whether a limitation, workaround, additional check, configuration change, or requalification activity is needed. Closing the software baseline while ignoring the qualification status of a relied-on tool leaves the certification argument incomplete.

FAA Order 8110.49A makes the end-state expectation practical: tools that require qualification should be qualified, and if qualification is incomplete at conformity, the tools and supporting data should at least have their configuration documented. That is not permission to defer the strategy. It underscores why version and environment control must exist before the final review.

The same boundary applies to reuse across projects. Prior qualification data may be useful when the new project can show that the required TQL, version, intended use, operational environment, procedures, and limitations remain applicable. A vendor kit or previous project package is evidence to assess, not a portable approval.

The takeaway: qualify a tool only when your project takes certification credit through an unverified output that could matter—and qualify only the exact use, configuration, and environment supporting that credit.

As your next step, use AeroCert’s free public-tier checklist library and select the Tool Qualification checklist. It walks through the qualification decision, planning approach, operational requirements, verification, configuration control, quality assurance, and final summary at a high level.

Primary sources

• FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), especially paragraphs 1, 6, and 10 for recognition of DO-178C and DO-330, applicant responsibilities, tool qualification, TQL determination, and legacy-tool transition guidance.
• FAA Order 8110.49A, Software Approval Guidelines, especially Chapter 1 definitions and Chapter 4 conformity guidance for certification credit, project-specific tool qualification, and tool-configuration expectations.
• RTCA DO-178C and companion standards, with the tool-qualification trigger and criteria in DO-178C section 12.2. The standard is copyrighted and available from RTCA; no proprietary table or objective text is reproduced here.
• RTCA DO-330, Software Tool Qualification Considerations, for the TQL-scaled objectives, activities, and life-cycle data used to qualify software tools under a DO-178C approach.

This article is educational guidance, not a project-specific compliance finding. Coordinate the software baseline, tool-credit strategy, qualification criteria, TQL, planned data, reuse claims, and review path with the responsible certification authority and authorized representatives.