Guide ยท Manufacturing & provisioning
How to share MAC address ranges with a contract manufacturer
You own the IEEE block; someone else builds the units. How to hand out addresses so a contract manufacturer can program every unit without ever being able to collide with your other production.
When a contract manufacturer (CM) or an ODM builds your product, the MAC addresses still come from your IEEE block and stay your responsibility. The CM needs enough to program every unit in a run and nothing more. This guide is the handoff.
Allocate an isolated range per factory
Do not give a CM the block. Give it a bounded subrange, modelled as its own portfolio or its own registered sub-block, with a hard upper limit. That range is the only address space the CM ever sees. Everything you build elsewhere is structurally out of its reach, so a mistake on their side cannot produce an address your own line already used. This is the same pattern as managing a pool across multiple factories.
Prevent overlapping assignments
Overlap is prevented by construction, not by trust: the CM's subrange does not intersect any other portfolio's range, and reservations within it are atomic, so even if the CM runs two lines at once they get adjacent, disjoint ranges. You never send "start at the next free address"; you send a specific reserved range.
Provide production-order exports
For each production order, generate a batch for exactly that quantity and send the CSV. Each row is a serial number, its MAC address, the device category, the portfolio, the block label, and the status. That file is the CM's instruction to the programming station and your record of what you authorised for that order.
serial_number,mac_address,device_category,portfolio,block_label,status
GW-26370000007,00:1B:44:11:20:00,router,CM-Shenzhen line,ACME MA-L,generated
GW-26370000015,00:1B:44:11:20:01,router,CM-Shenzhen line,ACME MA-L,generated
Record which identifiers were programmed
Ask the CM to return, per run, the list of identifiers actually written to units and which units failed final test. macadress.com does not read this back from the devices for you; it is data the CM produces on the line. Keep it against the batch so "reserved" and "programmed" are both known quantities.
Return unused ranges
A run of 5,000 that ships 4,600 leaves 400 reserved addresses unused. Split the batch at 4,600, mark the first part shipped, and release the rest. The released 400 become an explicit starting point for the next order. They are not deleted, not lost, and not handed out automatically.
Reconcile manufactured, failed and shipped devices
After each order you should be able to state, for that batch: how many were reserved, how many programmed, how many failed test, how many shipped. The shipped portion is marked permanent. Failed units' identifiers stay spent. The arithmetic closes, and it closes in a record you keep, not one held only at the CM.
Maintain an auditable source of truth
The point of all of this is that one system, held by you, is authoritative for every address in the block regardless of who built the unit. The CM works from exports of it; it does not hold its own copy of the allocation state. If the relationship ends, or you move to a second CM, the allocation history is intact and the new party gets its own fresh subrange.
Reference: IEEE Registration Authority. To allocate CM ranges from a block you hold, see MAC address allocation.
More guides