The November 2026 Deadline Is Real

The FDA's final DSCSA stabilization period ends in November 2026 for smaller dispensers, the last group to come into full compliance. After years of extensions, exemptions, and enforcement discretion, the agency has made clear: electronic, interoperable tracing at the package level is the expectation. Not the aspiration. The expectation.

If you are a manufacturer, wholesaler, repackager, or dispenser in the U.S. pharmaceutical supply chain, this checklist covers what you need to have in place. Not the vague compliance platitudes you find in most guides, but the specific systems, standards, and configurations that the FDA expects to see working.

Quick Background: Where DSCSA Stands in 2026

The Drug Supply Chain Security Act was signed in 2013 with a 10-year implementation timeline. The original target for full interoperable tracing was November 2023. The FDA granted enforcement discretion multiple times, pushing practical deadlines forward to give the industry time to build out infrastructure.

Here is what matters right now:

Manufacturers and repackagers should already be exchanging serialized transaction data electronically with trading partners
Wholesale distributors should be sending and receiving EPCIS events for every transaction
Dispensers have until November 2026 to participate fully in electronic, interoperable tracing
All entities must be able to respond to verification requests within 24 hours (one business day)

The FDA has also indicated it will begin requesting data from companies to assess industry readiness. If you get that request and your systems are not functional, you have a problem that no compliance consultant can talk you out of.

The 12-Point DSCSA 2026 Compliance Checklist

Work through each item. If you cannot check the box, that is your priority list.

1. Serialization at the Package Level

Every saleable unit in your supply chain must carry a unique product identifier. This is not optional, and it is not new, but some organizations are still applying serial numbers inconsistently or only at the case/lot level.

Your product identifier must include four data elements encoded in a GS1-compliant 2D barcode:

GTIN (Global Trade Item Number): the product's unique identifier
Serial number: unique to that individual package
Lot number: the manufacturing batch
Expiration date: in YYMMDD format per GS1 standards

Together, these four elements form the SGTIN (Serialized Global Trade Item Number). If your barcodes are not scannable, if your serial numbers are not unique, or if your GTIN assignments are inconsistent across NDCs, fix this first. Everything downstream depends on accurate serialization.

2. GS1 Company Prefix and GLN Registration

You need a GS1 Company Prefix to generate GTINs. You also need Global Location Numbers (GLNs) assigned to every facility that ships, receives, or stores pharmaceutical products.

GLNs are how trading partners identify your locations in EPCIS events. If your distribution center, your warehouse, and your headquarters all share a single GLN (or worse, have none), your EPCIS data will be ambiguous. The FDA expects location-level granularity.

Action items:

Register or renew your GS1 Company Prefix at gs1us.org
Assign GLNs to every physical location involved in pharmaceutical distribution
Publish your GLN data in the GS1 US GDSN or FDA-recognized databases so trading partners can resolve your locations

3. EPCIS Event Data Generation

EPCIS (Electronic Product Code Information Services) is the data format the industry has standardized on for DSCSA. Your system must generate EPCIS events for four core business steps:

Commissioning: when a serial number is created and associated with a product
Shipping: when product leaves your facility
Receiving: when product arrives at your facility
Decommissioning: when a serial number is retired (dispensed, destroyed, returned)

Each event must contain the SGTIN, event timestamp, business step, disposition, read point (GLN), and business transaction identifiers (purchase order numbers, invoice numbers).

If your ERP or warehouse management system does not generate EPCIS XML natively, you need middleware or a serialization platform (TraceLink, SAP ATTP, Antares Vision, rfxcel) that translates your internal data into compliant EPCIS documents.

4. EPCIS Document Validation

Generating EPCIS events is not enough. Those events must conform to the GS1 EPCIS 1.2 or 2.0 schema. Common issues we see in the field:

Invalid or missing bizStep URIs
Timestamps without timezone offsets
SGTINs formatted incorrectly (wrong URI structure)
Missing source/destination elements in shipping/receiving events

Validate your EPCIS documents against the GS1 XML schema before sending them to trading partners. Several GS1 validation tools exist, and most serialization platforms include built-in validation. Do not skip this step. Sending malformed EPCIS data to a trading partner causes rejections, delays, and compliance gaps on both sides.

5. Electronic Data Exchange Infrastructure

DSCSA requires electronic, interoperable exchange of transaction data. "Electronic" means no more paper pedigrees, faxed documents, or emailed spreadsheets. "Interoperable" means your system and your partner's system can exchange data without manual intervention.

The industry has converged on two primary transport mechanisms:

AS2 (Applicability Statement 2): the dominant protocol for direct, point-to-point data exchange. Encrypted, signed, with MDN receipts for non-repudiation. Most large manufacturers and wholesalers already use AS2 for EDI.
EPCIS Repository Access: some organizations use web services or APIs to query EPCIS repositories directly

For most companies, AS2 is the practical choice because trading partners already require it. Your AS2 configuration must support current encryption standards (AES-256), current signing algorithms (SHA-256), and TLS 1.2 or higher. If you are running legacy AS2 infrastructure with 3DES or SHA-1, you have a security and compliance gap.

6. Verification Router Service (VRS) Integration

The FDA requires that any trading partner in the supply chain be able to verify the authenticity of a product's serial number. This is the saleable return verification requirement, and it applies when product is returned or when there is a suspicion of illegitimacy.

Verification Router Services (VRS) are industry-built systems that route verification requests to the correct manufacturer. The two primary VRS systems are:

MediLedger: blockchain-based verification network
TraceLink DSCSA Verification Router: cloud-based routing service

If you are a manufacturer, you must be connected to at least one VRS and able to respond to inbound verification requests within 24 hours. If you are a wholesaler or dispenser, you must be able to send verification requests through a VRS and process the responses.

Test this now. Send test verification requests. Confirm your response times. A verification request that times out or returns an error is a compliance failure.

7. Trading Partner Authorization and Credentialing

DSCSA requires that you only transact with authorized trading partners. This means verifying that your partners hold valid state and federal licenses. The FDA maintains a Drug Establishment Registration database. State boards of pharmacy publish license databases.

Practically, this means:

Verify every trading partner's DEA registration or state license before the first transaction
Re-verify periodically (at least annually)
Maintain records of your credentialing checks
Refuse transactions with unlicensed or revoked entities

Some organizations use credentialing services (NABP, HDA) to automate this. If you have hundreds of trading partners, manual verification is not sustainable.

8. Suspect and Illegitimate Product Handling

You need documented procedures for what happens when you identify a suspect product. DSCSA defines specific obligations:

Quarantine the product immediately
Investigate within 24 hours
Notify the FDA and trading partners if the product is determined to be illegitimate
Maintain records of all investigations and outcomes

Your procedures must be written, tested, and known to the people who will execute them. A procedure that exists only in a binder on a shelf is not a procedure. Run a tabletop exercise: "A pharmacist scans a returned bottle and the serial number comes back as already dispensed. What happens next?" If your team cannot answer that in concrete steps, your suspect product process is not ready.

9. Data Retention (6 Years)

DSCSA requires that transaction information, transaction history, and transaction statements be retained for six years. This applies to electronic records, not just paper.

What this means for your systems:

EPCIS event data must be stored and retrievable for six years from the transaction date
AS2 message archives (payloads, MDN receipts) should be retained as proof of exchange
Your data retention policy must be documented and auditable
Storage must be secure: encrypted at rest, access-controlled, backed up

Calculate the storage requirements. A mid-size wholesaler processing 10,000 transactions per day generates roughly 15 to 20 GB of EPCIS data per year. Over six years, that is 90 to 120 GB of structured XML data, plus indices, plus backups. Plan your infrastructure accordingly.

10. System Interoperability Testing

The word "interoperable" appears throughout DSCSA for a reason. Your system must work with your trading partners' systems. Not in theory. In practice.

This means testing data exchange with every trading partner before go-live:

Send test EPCIS documents and confirm your partner can parse them
Receive test EPCIS documents and confirm your system can ingest them
Verify that serial numbers, GTINs, and GLNs resolve correctly on both sides
Test the full round-trip: ship event from you, receive event from partner, verification request, verification response

Do not assume that because two systems both claim GS1 EPCIS compliance, they will work together without issues. Schema versions, optional fields, extension elements, and transport configurations all create opportunities for failure. Test everything.

11. FDA Reporting Readiness

The FDA has the authority to request records from any entity in the supply chain. When (not if) they ask, you must be able to produce:

Transaction information for any product by serial number
Transaction history showing the chain of custody
Records of verification requests and responses
Documentation of suspect product investigations
Evidence of your trading partner credentialing process

Build the queries and reports now. Do not wait until the FDA sends a request letter and then discover that your data is scattered across three systems with no unified view. Practice pulling a complete product history by serial number. Time how long it takes. If the answer is "days," you have work to do.

12. Ongoing Monitoring and Maintenance

Compliance is not a one-time project. After November 2026, you must maintain:

Certificate renewals for AS2 connections (set alerts at 90, 60, and 30 days before expiry)
System updates for serialization platforms and EPCIS middleware
Trading partner onboarding processes for new partners
Annual review of procedures, policies, and system configurations
Staff training for anyone who handles serialized product or operates tracing systems

Assign ownership. "Compliance" is not a department. It is a set of specific responsibilities assigned to specific people with specific deadlines. If nobody owns the AS2 certificate renewal calendar, certificates will expire and connections will break.

How AS2 Fits Into the DSCSA Stack

Think of DSCSA compliance as a stack:

Data layer: GS1 standards (GTIN, GLN, SGTIN) define the identifiers
Format layer: EPCIS defines the event structure (XML documents)
Transport layer: AS2 carries the EPCIS documents between trading partners
Verification layer: VRS handles product authentication requests

Each layer depends on the one below it. If your AS2 transport is misconfigured, your perfectly formatted EPCIS data never reaches your trading partner. If your GS1 identifiers are wrong, your EPCIS data is useless regardless of how well your AS2 connection works.

Most compliance failures we see are not in the data or format layers. Companies invest heavily in serialization platforms and EPCIS generation. The failures happen in the transport layer: expired certificates, outdated encryption, untested connections, partners who changed their AS2 endpoint URL without telling anyone.

Validating Your AS2 Transport Layer

Before you declare your DSCSA infrastructure ready, test the AS2 connections that will carry your EPCIS data. Every connection. Not just the ones you use daily, but the ones you set up six months ago and have not touched since.

AS2 Certify validates the transport layer of your AS2 infrastructure. It sends test messages to your endpoint (or receives from yours), checks TLS versions, certificate validity, encryption algorithms, signing algorithms, and MDN exchange. You get a graded report showing exactly what passes and what needs attention.

For DSCSA preparation specifically, AS2 Certify helps you verify that each trading partner connection meets current security standards before EPCIS data starts flowing through it. Finding a misconfigured connection during testing costs you an hour. Finding it during an FDA inquiry costs you significantly more.

Start Now, Not in October

November 2026 sounds like it is far away. It is not. If you have 50 trading partners to onboard or re-validate, each one taking 5 to 15 business days, you need to start now. If you need to implement a VRS integration, budget 3 to 6 months for development, testing, and partner coordination. If your serialization platform needs an upgrade, that is a project with its own timeline.

Work through this checklist item by item. Assign owners. Set deadlines. Test everything. The companies that will be ready in November are the ones that started in April.