One Subscriber, One Device Identity

The same customer, four different records

In most ISP tool stacks, one subscriber exists as four unrelated records. There is an ACS entry keyed by a CWMP serial, an SNMP target keyed by an IP or sysName, a RADIUS session keyed by a username, and a billing account keyed by a customer ID — and nothing ties them together. So when a customer calls, support reconciles by hand: cross-reference the ACS, guess which SNMP target is theirs, find the RADIUS session, and match it to the billing account. Every minute of that is wasted, and every mismatch is a wrong action on the wrong line.

The fix is not another dashboard. It is a canonical identity: one subscriber → one site → one device, that every protocol's observations attach to. That is the core differentiator in the ISPAgents design contract, and the foundation everything else depends on.

Canonical identity from strong evidence

ISPAgents builds canonical identity from strong serial and MAC evidence. When a device presents a serial or MAC that uniquely identifies it, that evidence is hashed into a deterministic identifier (UUIDv5) — the same evidence always resolves to the same canonical device, so two protocols observing the same router land on one record rather than creating two.

Multi-protocol observations are then merged onto that record, tenant-scoped: TR-069, SNMP, USP, syslog, controller, and RADIUS signals all attach to one subscriber → site → device instead of living in six silos. The key word is evidence: identity is resolved deterministically when strong serial/MAC evidence exists, not by fuzzy guessing across every field.

What each signal contributes

Different protocols carry different identity evidence. The resolver uses the strong signals to anchor, and treats the rest as context on the same record:

No single signal does it alone. TR-069, USP, and SNMP carry the strongest hardware-rooted serial/MAC evidence; RADIUS and the controller bind that hardware to a subscriber and account; syslog adds the event timeline. Merged, they describe one device and one customer.

Why canonical identity is the differentiator

Once observations resolve to one subscriber, site, and device, the questions an ISP support and NOC team actually asks become answerable:

• Who is affected and what changed — an event maps to a named subscriber and site, not an anonymous IP, and the timeline shows the last config or firmware change.
• Is the fault CPE, Wi-Fi, access, backhaul, or upstream — because the CPE, the access device, and the upstream path are all on one identity graph, the platform can locate the layer instead of guessing.
• Suspend or restore with full context — a billing-driven access change runs against a device tied to a known subscriber, plan, and session, with the evidence attached.

This is what separates an ISP operations platform from a generic NMS bolted onto a separate billing tool. The protocols are table-stakes; resolving them onto one canonical, tenant-scoped identity is the product.

When evidence is missing

Identity is resolved from strong serial/MAC evidence when that evidence exists. It does not exist everywhere, and the honest design accounts for that:

• A syslog line or SNMP target with no strong serial/MAC may not auto-match to a canonical device.
• A RADIUS username may not yet be bound to a hardware identity.
• A controller record may reference a device the platform has not yet observed.

These unmatched observations are not silently dropped or force-merged onto the wrong record. They surface for operator attribution, so a human binds them to the right subscriber and device with the evidence in front of them — after which future observations on that evidence resolve automatically.

Where identity sits in the platform

Canonical identity is the foundation, not a feature. It is what lets unified device management present one device across every protocol, what makes network monitoring and alerts name the affected subscriber instead of an IP, and what gives zero-touch provisioning a deterministic device to claim into the right tenant on first contact. Get identity right, and billing, access, and support finally describe the same customer.