Standards · IUID Marking Guide
IUID Marking Guide: UII Constructs, the Registry, and Item Life Cycle.
The end-to-end view of IUID from a working label shop. What the program is, how UIIs are built, how the encoded payload is framed by ISO/IEC 15434, how the Registry record fits into delivery acceptance, and what happens to the identifier across the item’s life. Written for primes, subs, and program-office personnel who want a single practitioner reference.
What IUID is, in one paragraph
Item Unique Identification (IUID) is the DoD program that assigns a globally unique identifier — a UII — to each serially-managed tangible item the Department owns. The UII is encoded into a 2D Data Matrix symbol applied directly to the item (DPM) or onto a Class 1 label bonded to the item. Every UII is registered in the DoD IUID Registry and becomes the persistent identifier for the item across maintenance, configuration, financial, and disposition systems for the rest of the item’s service life. The program was established by Under Secretary of Defense policy in 2003, is governed today by DoDI 8320.04, and is enforced on contractors through DFARS 252.211-7003.
Why IUID exists
Before IUID, DoD’s systems of record tracked items by part number plus serial number, but the part-number and serial-number combinations were not guaranteed unique across the enterprise. A given part number could be issued by multiple suppliers, each with overlapping serial-number ranges. Two physically distinct items could legitimately carry the same part-number-plus-serial identifier in two different supplier registries and be ambiguous in DoD systems that aggregated data across sources.
IUID resolves the ambiguity by anchoring the identifier to a globally unique enterprise identifier — typically the supplier’s CAGE code — and concatenating it with the supplier’s serial or part-and-serial values. The resulting UII is unique for all time across all suppliers, because no two enterprises share an enterprise identifier and no enterprise issues the same serial twice. The Registry then aggregates UIIs across all DoD suppliers without collisions.
The practical consequences for the supplier are that the marking has to encode the enterprise identifier (the CAGE for most U.S. defense work), not just the serial number, and the marking has to be durable enough that the identifier remains readable over the item’s life. Both points are MIL-STD-130N territory; see MIL-STD-130N: Class 1 vs Class 0.
The UII: two constructs
A UII is built by concatenating fields from established enterprise-identifier systems. MIL-STD-130N recognizes two constructs.
Construct #1 — enterprise-wide serial
Construct #1 concatenates three fields:
- Issuing Agency Code (IAC) — one character identifying which system issued the enterprise identifier. D is the IAC for CAGE codes issued by DLA.
- Enterprise Identifier (EID) — the supplier’s identifier within the issuing system. For DLA-issued CAGE, this is the five-character CAGE code (e.g., 1ZYB4).
- Serial Number — unique to the enterprise across all items the enterprise has ever serialized.
Construct #1 is the right choice when the enterprise maintains a single serial-number sequence across all items it produces, regardless of part number. A small shop that issues serials sequentially as items leave the line will typically use Construct #1.
Construct #2 — per-part-number serial
Construct #2 concatenates three different fields:
- Enterprise Identifier (EID) — same as Construct #1, but without the IAC prefix because the part number scoped to the enterprise removes the need.
- Original Part Number — the supplier’s part number for the item.
- Serial Number — unique within that part number.
Construct #2 is the right choice when the enterprise resets serial numbers per part number. A high-volume manufacturer with thousands of part numbers and separate serial sequences per part will typically use Construct #2.
Construct selection is one-way per enterprise for any given product line. Switching constructs mid-stream produces non-unique UIIs in the Registry and is a program-office-level decision, not a per-order change.
How the UII is encoded: ISO/IEC 15434 Format 06
Encoding the concatenated UII into a Data Matrix is not just “put the string into the symbol.” The IUID payload is wrapped in an ISO/IEC 15434 Format 06 envelope so that any compliant reader can parse it. The envelope consists of:
- Header — [)>RS06GS indicates a Format 06 payload follows (the RS and GS are ASCII control characters: Record Separator 0x1E and Group Separator 0x1D).
- Data Identifiers (DIs) — each field is preceded by a DI that tells the parser what the next substring is. The DIs are defined in ANSI MH10.8.2. Common IUID DIs include 17V (EID under CAGE), 1P (original part number), S (serial), and 25S (UII as a complete string).
- Field separators — GS between fields.
- Trailer — RSEOT closes the envelope.
A symbol that contains the concatenated UII as a bare string — without the Format 06 envelope — will scan and decode to the UII text, but will be rejected by the IUID Registry ingest because the parser cannot identify which substring is the EID, which is the part number, and which is the serial. This is one of the most common encoding failures in IUID work.
The IUID Registry
The DoD IUID Registry is the system of record for UIIs. It is accessed today through the Procurement Integrated Enterprise Environment (PIEE), the DoD’s consolidated contractor portal that combines the legacy Wide Area Workflow (WAWF), the IUID Registry, and several other procurement-adjacent systems under a single sign-on.
For each marked item, the contractor submits a Registry record containing:
- The complete UII string
- The enterprise identifier as a separate field
- Part number and serial number as separate fields, mirroring the UII construct
- The marking method (label, dot peen, laser etch, etc.)
- The acquisition cost (the “valuation” half of DFARS 252.211-7003)
- Contract number, line item, and delivery information
The receiving inspector at the using activity scans the symbol on the item, looks up the UII in the Registry through PIEE, and confirms that the registered record matches the contract line, the part, and the expected serial. If the lookup fails or the registered record disagrees with the physical item, DD-250 acceptance is held until the discrepancy is reconciled.
Lifecycle: what the UII does after registration
The UII is registered at delivery, but it lives for the full operational life of the item. Across that life, the UII becomes the persistent key in every DoD system that touches the item:
- Receipt and custody. The using activity records receipt of the item against the UII; subsequent custody transfers between units, depots, or contractors are logged against the same UII.
- Maintenance. Maintenance actions performed on the item — scheduled inspection, repair, calibration, configuration change — are recorded in maintenance systems with the UII as the item key.
- Configuration management. When the item is part of a higher-level assembly, the UIIs of components and the parent item are linked in configuration-management systems so the program office can trace which components are installed where.
- Financial. The acquisition cost recorded at registration feeds asset-valuation reporting; depreciation and end-of-life value flow through financial systems keyed by the UII.
- Disposition. When the item is retired, transferred out, demilitarized, or disposed, the UII record is closed in the Registry but not deleted; the historical record persists.
None of this lifecycle activity is the supplier’s responsibility once the item is delivered and the UII is registered. But it does explain why the durability of the physical mark matters: a label that delaminates in year three of a twenty-year service life breaks every downstream system that relies on the UII as the item key.
The most-misunderstood IUID details
- The UII is the encoded string, not the human-readable text. The alphanumeric printed next to the Data Matrix is for human eyes; the legal identifier is the encoded payload. Reading them out of sync is a recurring error.
- The Format 06 envelope is not optional. A symbol encoding just the concatenated UII string will scan and decode but will not register.
- Construct #1 and Construct #2 are not interchangeable for a given item. Once an item is registered with a UII built one way, it cannot be re-registered with a UII built the other way without going through a UII Marking Verification process.
- UIIs are not recycled. Disposal closes the record; the identifier is not re-used for a new item.
- The Registry is authoritative; the physical mark is a local copy. When they disagree, the inspector trusts the Registry and rejects the item until the mark is fixed.
- CAGE under IAC D is the right choice for U.S. defense suppliers. Using GS1 or another issuing system without explicit program-office direction creates compatibility friction with downstream DoD systems that expect CAGE-based UIIs.
- The acquisition cost is reported at registration, not at marking. The valuation is a contract-level fact, not a substrate property. The labeling shop does not need to know the cost to produce the label; the prime needs to know it to register.
How Front Range Marking handles IUID production
Front Range Marking produces IUID labels on UL-recognized polyester with resin ribbon, encodes the UII into a 2D Data Matrix using the ISO/IEC 15434 Format 06 envelope, and verifies every symbol against ISO/IEC 15415 grade B (or higher when the contract requires it) before the label leaves the press. Construct #1 and Construct #2 are both supported; the prime or program office specifies the construct, and FRM encodes accordingly.
FRM does not perform IUID Registry submission for the prime. The Registry submission is part of the prime’s contractual relationship with the government and depends on data — acquisition cost, contract line item, delivery schedule — that the prime holds and the labeling shop does not. FRM provides the data the prime needs: verified UII per item, marking method, substrate, verification grade, lot identification.
Frequently asked questions
What is IUID?
Item Unique Identification — the DoD program that assigns a globally unique identifier (UII) to each serially-managed tangible item, registers it centrally, and uses it as the persistent key across maintenance, configuration, financial, and disposition systems.
How is a UII constructed?
Two constructs: #1 is IAC + EID + enterprise-wide Serial; #2 is EID + Original Part Number + per-part Serial. Choice depends on how the enterprise serializes.
What is ISO/IEC 15434 Format 06?
The envelope that wraps the encoded UII in a Data Matrix. Includes header, data identifiers, field separators, and trailer. Required for IUID Registry ingest.
Who issues the Enterprise Identifier?
For U.S. defense suppliers, the Defense Logistics Agency under IAC D (CAGE codes). Other issuing systems exist but CAGE is the dominant choice for DoD work.
How does the Registry record relate to the physical mark?
The mark is the local copy; the Registry is the canonical record. The receiving inspector confirms they match at DD-250. Mismatches hold acceptance.
What happens to a UII across the item’s life?
It becomes the persistent identifier for receipt, custody, maintenance, configuration, financial, and disposition systems. The supplier’s responsibility ends at registration; the UII’s use begins.
Can a UII be re-used after disposal?
No. UIIs are globally unique for all time. Disposal closes the record but does not recycle the identifier.
Does IUID apply outside DoD?
The DoD IUID Registry is DoD-only, but the underlying ISO/IEC 15459 enterprise-identifier framework is used in civil aviation (FAA), automotive (VIN), and pharmaceuticals (UDI). A supplier producing IUID marks is positioned to support compatible unique-identification programs in those domains.
Contact
Request a Quote or Capability Statement
Joshua Hickman, Principal · Longmont, Colorado · Quote in one business day
Prefer email? joshua@frontrangemarking.com