An equipment identity register (EIR) is the network database a mobile operator uses to decide whether a device may use its network, based on the device’s IMEI. When a handset attaches or performs certain network procedures, the core network checks its IMEI against the EIR and gets back a verdict: allowed, blocked, or flagged for monitoring. That makes the EIR the practical enforcement point for stolen-device control, counterfeit-device screening and regulatory device registration across 2G, 3G, 4G and 5G.
For many operators, the EIR stays an afterthought until a regulator, a theft-prevention initiative or a 5G core rollout puts it on the agenda. This guide covers what operators need to know.
What is an equipment identity register?
The EIR is a core network element defined in 3GPP specifications. It holds lists of device identities and returns a status whenever a network node asks about a particular device. The identity it works with is the International Mobile Equipment Identity (IMEI), a number assigned to each device by its manufacturer.
A standard IMEI has 15 digits:
- Type Allocation Code (TAC): the first 8 digits, allocated through the GSMA, identifying the device make and model.
- Serial number: 6 digits assigned by the manufacturer to the individual unit.
- Check digit: a single digit used to validate the number.
A related format, the IMEISV, replaces the check digit with a two-digit software version number. Networks commonly request the IMEISV during attach procedures.
The key distinction for operators is that the IMEI identifies the device, while the IMSI on the SIM identifies the subscriber. Blocking a SIM stops a subscription; blocking an IMEI stops the handset, no matter which SIM is inserted. That makes the EIR the right tool for device-level policy.
How an equipment identity register works
The basic interaction is simple and happens at high volume:
- A device attaches to the network or triggers a procedure where the operator’s policy calls for an identity check.
- The serving core node requests the IMEI or IMEISV from the device.
- The core node sends an identity check request to the EIR.
- The EIR looks up the device and returns its status.
- The core node allows service, rejects the device, or allows service while recording the event, depending on the result and local policy.
White, grey and black lists
Most EIR implementations organize devices into three lists. The exact behavior is configurable, but the general model is consistent across vendors and regions.
| List | Meaning | Typical network action |
|---|---|---|
| White list | Device is approved or registered | Allow normal service |
| Grey list | Device is under observation, such as unregistered during a grace period or suspected of misuse | Allow service, log usage, optionally notify the subscriber |
| Black list | Device is reported stolen, lost, invalid or barred by regulation | Reject network access |
Many EIR platforms go beyond the three lists. Common extensions include IMSI-IMEI pairing (tying a device to the SIM it was first seen with), detection of the same IMEI appearing on multiple subscriptions at once, and TAC validation to flag numbers that do not match any allocated device model.
Stolen-device control and IMEI blacklisting
Theft deterrence is the most familiar use of the EIR. If a stolen phone can be blocked from every network it might use, its resale value drops sharply. The workflow usually looks like this:
- The subscriber reports the theft to customer care, often alongside a police report.
- The operator verifies the account and adds the device’s IMEI to its black list.
- The IMEI is shared with other operators through industry or national databases.
- Any network that checks the IMEI against those lists rejects the device.
Step 3 is what makes blacklisting effective, since a device blocked on one network can otherwise move to a competitor. The GSMA operates a shared IMEI database for participating operators, and some countries run national central registers. Coverage depends on participation and sync frequency, so cross-border gaps can remain.
Operators should also plan for:
- Reversal: removing a device from the black list when it is recovered or a report proves mistaken.
- Audit trails: recording who blocked or unblocked a device and why.
- Fraud controls: protecting the blocking process so it cannot be abused against legitimate customers.
Whitelisting and regulatory device registration
Where blacklisting blocks known-bad devices, whitelisting allows only known-good ones. Several regulators in different parts of the world have introduced national device registration programs built on this model. A central system holds the registered IMEIs, and operators are required to check devices against it or synchronize it into their own EIRs.
Policy goals vary by market but commonly include reducing counterfeit devices, supporting import and tax compliance, and discouraging theft. For operators, a mandate typically means:
- List synchronization with a central register, on a schedule or in near real time.
- Grace periods during which newly seen, unregistered devices remain on the grey list before being blocked.
- Subscriber notification, usually by SMS, telling users that a device must be registered or will be disconnected.
- IMSI-IMEI pairing, so a device registered to one subscriber is not reused freely on another.
- Exemptions for inbound roamers and other cases defined by the regulator.
- Reporting back to the regulator on device activity and enforcement actions.
These programs tend to arrive with fixed deadlines, so a flexible EIR that adapts through configuration rather than replacement is a real advantage.
The EIR in 4G and 5G networks
The EIR’s role stays the same across generations, but the network element asking the question and the protocol it uses change.
| Generation | Querying network element | Interface and protocol | Device identifier |
|---|---|---|---|
| 2G / 3G | MSC/VLR and SGSN | MAP over SS7 or SIGTRAN | IMEI / IMEISV |
| 4G LTE | MME | S13 interface using Diameter | IMEI / IMEISV |
| 5G standalone | AMF | N5g-eir service-based interface (HTTP/2) | PEI, typically an IMEI or IMEISV |
In the 5G standalone core, 3GPP defines the 5G-EIR as an optional network function. The AMF can query it during registration to check the device’s Permanent Equipment Identifier (PEI). Because it is optional, whether an operator deploys one depends on its own fraud and theft policy, and on any regulatory requirements in its market. In non-standalone 5G deployments, the LTE core remains the anchor, so device checks continue to run through the MME and the S13 interface.
The practical lesson is consistency. If 4G blocks a device but 2G/3G or 5G does not, the device simply uses the unenforced path. One EIR, or a tightly synchronized set, serving every generation closes that gap.
What operators should evaluate in an EIR
- Protocol coverage: MAP over SIGTRAN, Diameter S13, and a clear path to the 5G service-based interface.
- Availability: identity checks sit in the attach path, so the EIR needs redundancy and a defined policy if it cannot be reached.
- List management: bulk import, APIs and automated sync with national and industry databases.
- Advanced checks: IMSI-IMEI pairing, duplicate IMEI detection and TAC validation.
- Notifications: triggering SMS to affected subscribers through the SMSC.
- Reporting and audit: logs suitable for regulators, fraud teams and customer care.
- Deployment model: support for virtualized and containerized environments.
How Primal Technologies helps
Primal Technologies has supplied value-added services and billing platforms to mobile, landline and cable operators since 1997. Its Equipment Identity Register is part of a broader portfolio that includes SMSC, IP-SM-GW, OCS/prepaid billing, PCRF, USSD and OTA provisioning, built on long experience with TCAP, SIGTRAN, DIAMETER and SIP signaling.
That breadth matters for EIR projects. Device registration programs depend on subscriber notifications, which Primal can support through its SMSC and messaging platforms. Integration with care systems, central registers and existing core nodes is handled through Primal’s professional services team, which covers consulting, deployment, support, NFV and containerization. Operators that want to reduce on-premises footprint can also look at Primal Cloud, built on OpenShift, Rocky Linux and Kubernetes.
Primal works with operators across North America, the Caribbean, Africa, Europe and the Pacific Rim, adapting to different regulatory environments.
Frequently asked questions
What is the difference between an EIR and an HLR or HSS?
The HLR (2G/3G) and HSS (4G/IMS) store subscriber data tied to the SIM and IMSI. The EIR stores device data tied to the IMEI. One controls who the subscriber is; the other controls which handset is allowed on the network.
What is the difference between IMEI blacklisting and whitelisting?
Blacklisting blocks specific devices, such as those reported stolen, and allows everything else. Whitelisting allows only devices that are registered or approved and blocks the rest. Many national registration programs use whitelisting with a grey-list grace period.
Does changing the SIM card get around an EIR block?
No. The EIR checks the device’s IMEI, which does not change when a different SIM is inserted. Illegal IMEI tampering does exist, which is why duplicate IMEI detection and TAC validation are useful EIR features.
Is a 5G-EIR mandatory?
Not under 3GPP specifications, where it is an optional network function. Operators deploy it based on their own fraud and theft policies or when a regulator requires device checks in 5G standalone networks.
Can operators share blacklists with each other?
Yes. The GSMA’s shared IMEI database lets participating operators exchange blacklisted devices, and some countries operate national central registers. Effectiveness depends on how many operators participate and how often lists are synchronized.
Whether you face a device registration deadline, need stronger stolen-device controls or are planning a 5G core, Primal Technologies can help you design and deploy an EIR that works across every network generation you run. Request a demo to discuss your requirements with our team.