Managing 1,000 SIM Cards Across Sites: Inventory, Access and Reconciliation

Managing 1,000 SIM cards across sites fails for administrative reasons long before it fails for technical ones. The hardware keeps working; what breaks is the ability to say which card is where, what it is for, and whether it should still be in service.

This article sets out what breaks first at this scale, why the inventory has to be keyed on the SIM rather than on the slot it occupies, how to centralise the estate without necessarily centralising the radios, how to reconcile the register against what the equipment reports, and the access and change records that keep the whole thing auditable.

What breaks first when you manage 1,000 SIM cards across sites?

Identity, then purpose, then accountability.

The first casualty is the ability to identify a card, the second is knowing why it exists, and the third is knowing who is responsible for it — and each failure makes the next one harder to correct.

Identity breaks because cards move. A card installed in one slot is moved during maintenance, a bank is re-cabled, a module is replaced, and the record that associated the card with a slot becomes wrong without anyone noticing. Purpose breaks because a deployment that grows from tens to hundreds of cards accumulates cards that were added for a campaign that ended, and nobody removes them because nothing records what they were for. Accountability breaks because the register, the equipment configuration and the operator account list are maintained by different people who each assume the others are accurate.

The order matters, because fixing identity without fixing purpose produces an accurate record of cards nobody should be using. The register has to hold both, and it has to be the place where the answer is looked up rather than a document that describes what someone believed at the time. Numbering that identifies a subscription is standardised under the ITU-T E.118 recommendation for the card identifier and ITU-T E.212 for the network identity, and those two identifiers are the natural keys for the register.

What breaks	How it shows up	What fixes it
Card identity	The register describes a slot the card has left	A register keyed on the card identifier
Purpose	Cards in service with no owner and no campaign	A required purpose field with a review date
Accountability	No one can approve a change to a card	Access control with named owners
Reconciliation	Register and equipment disagree, nobody knows which is right	A scheduled comparison against reported state

Why key the inventory on the SIM rather than the slot?

Because the card moves and the slot stays.

A slot-based register becomes wrong every time a card is moved, while a card-based register stays correct and records the move as an event.

That single design choice determines how much maintenance the register needs. In a slot-keyed system, every physical change requires someone to remember to update a row, and the update is easy to forget because the equipment continues to work. In a card-keyed system, the physical location is an attribute with a history, and a discrepancy between the register and the equipment is a finding rather than an error.

Keeping history rather than only current state is what makes the register useful during an investigation. When a number is suspended, the first questions are which card it belongs to, where that card has been, and which site and campaign it served. A register that overwrites the previous location can answer only the first. Recording each move with a timestamp and an actor answers all three.

Purpose as a required field

A card without a purpose is a card nobody will remove.

Requiring a stated purpose, an owner and a review date turns an estate of unknown cards into one that can be audited, and it makes decommissioning a normal event rather than an unusual one.

The purpose field should be specific enough to be checkable. “Marketing” is not a purpose; “order notifications for the retail campaign in market A, reviewed each quarter” is. The test is whether a person who was not present when the card was added could decide whether it is still needed, and vague entries fail that test immediately.

The review date is the mechanism that makes the field real. Cards whose review date has passed appear on a list, and the list is short enough to work through because it only contains entries that were never updated. Without a review date, the purpose field becomes a description of history rather than a control, and the estate grows by accumulation as it always does.

One more field earns its place in the register: the date the card was last seen by the network. A card that has not been observed for weeks is either sitting in a spare box or missing, and the two are indistinguishable without the record. The date costs nothing to maintain where reconciliation already reads reported state.

Centralising the estate versus centralising the radios

They are different decisions with different costs.

Centralising the cards puts the subscriber identity in one place and leaves the radios distributed; centralising the radios puts the transmission in one place and leaves the cards wherever they are installed.

Centralising the cards is what SIM bank and SIM pool hardware does, and its benefit is administrative: one place to issue, move and remove, with the allocation recorded automatically. The cost is a dependency on the link between the bank and the gateways, which appears in the command timing of anything that uses the signalling channel and in the failure domain of everything that depends on that link.

Centralising the radios concentrates coverage and simplifies physical maintenance, at the cost of a single site dependency and a single environmental risk. Most large estates end up with a mixture: cards centralised for the bulk of the estate, with radios placed where coverage is best, and a small number of local installations where the link dependency is unacceptable. Writing down which parts of the estate follow which model is what prevents a new site from being added to the wrong one.

How do you reconcile the register against reported state?

Compare on a schedule and treat differences as findings.

Reconciliation reads what the equipment reports, compares it with the register, and produces a list of discrepancies for someone to resolve rather than an automatic correction.

Automatic correction is tempting and wrong. A discrepancy has several possible causes — a card moved without a record, a card replaced during a repair, a register entry out of date, or a genuine fault — and only a person can tell which. The reconciliation job should therefore produce evidence, not state, and the evidence should include the time of the comparison and the state of both sides.

Run the comparison often enough that discrepancies are few. A monthly sweep on an estate of a thousand cards produces a long list that nobody works through; a daily sweep produces a short one that gets resolved. Where the equipment supports an interface for reading per-slot state, the same interface that the command specifications describe in ETSI TS 123 040 and the related device specifications can be used for the automated half of the comparison.

Record the reconciliation result even when it is clean. The pattern of discrepancies over time is what identifies the processes that create them, and a clean run is evidence that the previous fix worked.

Access control and change records

Two questions, one record each.

Who may change the estate, and what changed — and the answers have to be findable without asking the team.

Access control on an estate of this size has three layers: who may add or remove a card, who may change a routing or product configuration, and who may change a subscription with the operator. Each layer is usually held by a different group, and the estate is vulnerable where one of them is unowned. Naming the owner per layer is the control; the technology is secondary.

The change record should capture the card identifier, the change, the timestamp and the actor, and it should be written by the process rather than by hand. Record-keeping discipline for operational systems is covered in NIST SP 800-92, and the access-control objectives that translate into concrete measures are organised in NIST SP 800-53 Rev. 5. The practical test of both is the same: if a card stops working on a given date, can you find out who touched it?

A register template

A workable register has a small set of columns and a large set of rows, and it is better to keep it small than to keep it complete.

1. Card identifier and network identity, as the two keys.
2. Operator, market and tariff.
3. Current location: site, unit and slot.
4. Purpose, owner and review date.
5. Status: in service, spare, quarantined or retired.
6. Last reconciliation date and result.
7. Move history with timestamps and actors.

The attach and registration states that a card passes through when it is installed are defined in 3GPP TS 24.301, and knowing them makes a card that is present but not serviceable distinguishable from one that is absent. That distinction is the difference between a reconciliation finding and a report of a missing card, and the register should be able to express both.