DoDIN APL Changes: How to Verify Products After the Shift

That answer is less convenient than checking one list. It is also closer to what a defensible purchase decision has always required. A product name without a version, role, and evidence date tells an approver very little.

The sunset happened in stages, and those dates matter when someone presents an old screenshot as current proof.

DISA's official APL site states that the DoDIN APL was formally sunset on September 30, 2025. Scheduled testing concluded on December 31, 2025. The repository is being maintained through fiscal year 2026 so users can retrieve historical material and the remaining test pipeline can be resolved, but the site also warns that the list is no longer being updated after final pipeline items.

DISA's sunset FAQ separates two jobs that buyers often combine under the phrase “APL approval.” Cybersecurity validation transitions toward the DISA Risk Management Executive Vendor STIG process. Interoperability requirements transition toward UCR-CORE and contract-based enforcement. Those tracks can meet again in a solicitation, but they do not prove the same thing.

This is why a reseller letter saying “APL compliant” should trigger a follow-up rather than close the file. Ask which requirement the statement addresses, which official record supports it, and which exact configuration was evaluated.

An archived entry can be useful. It may show that a named product and release completed a particular testing path, identify a certification date, or point to configuration notes. It can also help explain why an existing environment standardized on a product family.

Use the record as a dated artifact:

Do not silently carry the result from an older release to a current one. A switch running a later operating-system train, a session border controller with different licensing, or an appliance with a changed cryptographic module may need different evidence. Similar branding is not configuration equivalence.

Start here, not with a marketing page. Search the statement of work, technical exhibits, clauses, brand-name-or-equal language, approved-product references, data-item requirements, and security attachments. Write down the exact sentence that creates the obligation.

If the document still says “must be on the DoDIN APL,” do not invent a replacement on the buyer's behalf. Submit a written question: Is an archived entry acceptable? Is a current Vendor STIG package required? Which UCR-CORE or interoperability evidence will the agency accept? Who can approve an exception? A written answer protects both evaluator and vendor from solving different problems.

Use the official DISA repository at aplit.disa.mil, not a distributor's copied list. Search the exact model and product family. Check whether the entry describes the offered release. Read notes and limitations. If no entry appears, that absence does not automatically mean “prohibited”; it means the historical list does not supply the proof being requested.

The DoD Cyber Exchange publishes Security Technical Implementation Guides and related content. Determine whether there is a product-specific STIG, a technology-level STIG, a Security Requirements Guide, or vendor-supplied content under the transition process. A STIG is a configuration and assessment resource. It is not, by itself, a procurement authorization or a promise that a product meets every requirement.

The useful procurement question is concrete: Which STIG or SRG applies to this version, which findings are expected at deployment, and who owns remediation or accepted exceptions? Ask for the answer before an item reaches the loading dock.

For Unified Capabilities, identify the applicable UCR-CORE requirements and any program-specific interoperability evidence. A security configuration guide cannot prove call-control behavior, network interoperability, quality-of-service performance, or every mission-thread requirement. Conversely, a successful interoperability test does not settle supply-chain or hardening questions.

The contract may require a test report, certification, lab result, first-article test, or agency acceptance activity. Record the document name, revision, issuing authority, scope, and expiration or supersession status rather than summarizing it as “approved.”

Describe what the product will do and where it will run. “Network appliance” is not enough. State whether it terminates voice, routes mission traffic, provides wireless access, handles management-plane data, or sits outside the DoDIN boundary. The role determines which requirements deserve attention.

Create a configuration snapshot with manufacturer, ordering SKU, model, modules, power supplies, licenses, subscription tier, operating system, firmware, and any embedded radios. Include country-of-origin and supply-chain fields if the acquisition requires them. Give the snapshot a date and revision number.

Use one row per requirement. Suggested columns are:

The matrix prevents one document from being stretched to cover requirements it never addressed.

Avoid “Is this DoD approved?” It invites an equally vague answer. Ask:

Keep the signed response with the quote revision it supports. A link that changes after award is poor audit evidence.

Classify each gap as blocking, clarifying, or operational. A blocking gap means the offered configuration cannot yet be shown to meet a mandatory requirement. A clarifying gap needs an agency interpretation. An operational gap can be closed during staging or deployment if the contract allows it and names the owner.

Do not hide gaps in a general “compliant” column. State the evidence missing, the person empowered to accept it, and the deadline. If an exception is granted, retain the actual approval and its scope.

Configuration drift often occurs between technical selection and fulfillment. The quote may substitute a power supply, wireless module, revision, or license. Require the final purchase order and advance ship notice to be checked against the approved configuration snapshot. When serial-number or firmware capture is required, add it to receiving.

A reviewer should be able to reconstruct the decision without calling the original buyer. Include:

File names should carry dates and versions. “APL.pdf” will become meaningless six months later. A name such as `OEM-model-release_APL-archive_retrieved-2026-08-15.pdf` is less elegant and far more useful.

A useful requirement names the outcome, evidence, timing, and acceptance authority. For example:

That sample is drafting guidance, not contract language for every program. Contracting counsel and the authorizing organization should tailor it. Its value is that it prevents “APL approved” from standing in for five unanswered questions.

Place a short cover sheet over the evidence packet. It should state the requirement, offered configuration revision, intended operational role, official sources checked, historical APL result, current STIG/SRG result, current interoperability result, open conditions, and approving owners. Include an “evidence as of” date.

The conclusion should be narrow: “Evidence supports selection for the stated requirement and configuration, subject to the listed deployment conditions.” Avoid “DoD approved” or “APL compliant” unless the controlling authority uses that exact language and explains its post-sunset meaning.

List changes that trigger review: model or module substitution, firmware/software release, license tier, intended network role, STIG revision, interoperability requirement, or contract amendment. This turns the packet into a maintained decision record instead of a one-time screenshot.

Give the cover sheet a decision owner and next-review date. For a deployed product, tie the next review to a version change, vulnerability response, support milestone, or contract option—not an arbitrary annual reminder. If the product never changes, the official requirements still might.

Close the review only when every condition has an owner, due date, and acceptance authority. “Pending” is a status, not an approval.