Extended Unique Identifier 64 is a method for forming a 64-bit IPv6 interface identifier from a 48-bit hardware address. It inserts fixed bytes into the middle of the MAC address to create the lower half of an IPv6 address, although modern networks often avoid using it because it reveals device identity.
How EUI-64 Works
EUI-64 is a way of deriving a 64-bit IPv6 interface identifier from a 48-bit hardware address. The method is mechanically simple, but it is important to understand that the resulting identifier is not random. It is derived from the underlying device address, which is why it can be predictable and linkable across networks.
In practice, the transformation inserts fixed bytes into the middle of the original address and adapts the value so it fits the IPv6 interface-identifier format. That design made early IPv6 autoconfiguration straightforward, but it also meant the identifier carried information that was not meant to be broadly exposed.
Why EUI-64 Exposes Device Identity
The main security concern with EUI-64 is privacy and traceability. Because the interface identifier is derived from a hardware address, observers may be able to infer that two IPv6 addresses belong to the same device, even when the device moves between networks. In modern environments, that makes it a weak choice for exposing endpoints that should not be trivially correlated.
This is one reason many networks prefer privacy-oriented IPv6 addressing methods instead of stable identifiers built from hardware values. When an address embeds a persistent device-derived pattern, it can create long-lived tracking value for internal monitoring, passive reconnaissance, and external observation.
Where EUI-64 Still Appears
EUI-64 is most closely associated with IPv6 interface autoconfiguration and with legacy design choices that favoured consistency over privacy. It can still appear in network documentation, device fleets, lab environments, and older deployments where address stability was valued or where defaults were never revisited.
It is also useful as a concept for understanding IPv6 addressing behaviour more broadly. Even when an organisation does not intentionally use EUI-64, similar stable identifier patterns can emerge from template-based provisioning, vendor defaults, or address assignment methods that preserve device-specific information.
Safer IPv6 Addressing Choices
For most production environments, the practical question is not whether EUI-64 works, but whether it should be used at all. If address privacy matters, organisations generally prefer methods that avoid embedding a hardware-derived identifier in the IPv6 interface ID. That reduces passive linkability and makes endpoint enumeration less straightforward.
When stable identification is required for operations, it is better to separate addressing from identity assumptions. Network teams should treat the interface identifier as an addressing detail, not as a trustworthy identity control, and should use explicit asset, host, or device management sources when they need to know what a system actually is.
Risk and Threat Considerations
EUI-64 can expose more than many teams expect because the identifier may be predictable, persistent, and correlated across networks. That creates privacy risk, and in some environments it can also assist reconnaissance by making device tracking and inventory inference easier.
Failure mechanism: The address derivation leaks a stable relationship to the original hardware value, so passive observers can correlate systems even when they change location, network, or segment.
Impact: Attackers or internal observers may gain easier endpoint tracking, improved targeting for follow-on reconnaissance, and a clearer view of where a device has appeared over time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | EUI-64 affects how devices are identified and tracked on IPv6 networks. |
| Recommendation — Inventory IPv6-enabled devices so interface identifiers are not mistaken for authoritative asset identity. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Stable IPv6 identifiers can leak asset linkability and complicate asset governance. |
| Recommendation — Maintain an asset inventory that does not rely on EUI-64-style addressing for identity. | ||
| NIST SP 800-53 Rev 5 | IA-3 — Device Identification and Authentication | Hardware-derived interface identifiers can be confused with device identity in access and trust decisions. |
| Recommendation — Use explicit device authentication rather than IPv6 interface identifiers as proof of device identity. | ||
Practitioner Guidance
Why practitioners should care: Treat EUI-64 as an addressing design choice with privacy consequences, not as a neutral formatting detail. If a device’s IPv6 address should not advertise a stable hardware-derived pattern, prefer an addressing approach that does not reveal it.
What to watch for: Review IPv6 configuration standards, provisioning templates, and legacy network defaults to see where EUI-64 may still be enabled or implicitly inherited. If stable interface identifiers are present, align the address plan with the operational need for privacy, traceability, or both.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org