Everything worth knowing, nothing that isn't.
What it actually does
Every SM-DP+ profile download is bound to one specific EID — the profile is encrypted with a key derived from that eUICC's certificate, so it can only be installed on that physical chip. Operators register EIDs in their eUICC inventory at the moment of subscription; SM-DS uses EID to route discovery events back to the right device. EID is structured: the first 8 digits identify the eUICC issuer (per GSMA registration), the next 8 identify the manufacturer, the next 16 are the serial; the final two are a Luhn check digit pair.
Why it matters commercially
EID is the device-side primary key in every eSIM commercial flow. An operator that loses track of EIDs cannot reconcile its subscription database with the eUICC fleet; an IoT customer that does not capture EIDs at procurement cannot pre-stage profiles before deployment. The classic mistake is treating EID as a printable QR-code value — it is, but it is also a piece of inventory data that needs to flow through the manufacturing → distribution → activation → support chain in a structured way. BroadNet's eSIM VSM platform (/operators/esim-vsm) ships an EID lifecycle module that integrates with ERP and field-service systems.
Latency, scale, and compliance angle
EID lookups inside SM-DP+ and SM-DS are sub-millisecond — they index everything. Compliance: EID is not personal data on its own (it identifies a chip, not a person), but once bound to an MSISDN or IMSI it becomes a quasi-identifier and inherits PDPL / GDPR scope. Operators that pool EIDs across markets must consider the cross-border transfer impact of moving the EID-to-MSISDN mapping table.
Privacy and compliance considerations
Treat EID as semi-sensitive: don't print it on packaging that ships open, don't log it in plaintext to third-party analytics. Mature operators tokenise EID downstream of the SM-DP+ for analytics use. For SAS-SM-audited deployments, the EID inventory database is in scope for access-control review.