The Problem With Contact ID In The Digital Age.
The Problem With Contact ID – Contact ID is the most widely spoken language in alarm monitoring. It is also the wrong one for the century we are working in, according to Lee Chua of BENS Monitoring.
Walk into almost any monitoring centre in the world and you will find Contact ID. It is the lingua franca of alarm signalling, the format panels reach for, receivers expect and automation software is built around. It has earned that ubiquity honestly. For a reporting protocol to remain dominant almost 40 years after it appeared is no small achievement.
But ubiquity is not the same as fitness for purpose. After 4 decades on the receiving end of these signals, I think it is worth saying plainly: the format we depend on carries a design flaw baked in at birth, and the industry has spent 30 years quietly working around it rather than fixing it.
A Child Of The Telephone Network
To understand the trouble, it helps to remember where Contact ID came from. It rose to prominence through the 1980s and 1990s, in the era of decadic and DTMF signalling over the public telephone network. Those were its design constraints. A panel seized the line, dialled the central station and conveyed an entire alarm event as a short burst of tones before hanging up. Every decision in the format was shaped by the cost of sending information that way: keep it short, keep it numeric, keep it fast.
It replaced the older 4+2 format, with 4 digits for the account number and 2 for the event code, and was a genuine step forward, carrying far more information in a single call. Monitoring centres of the day ran software such as Ademco’s CAPS, with the limited database architecture of the time, and Contact ID fitted that world well. It was fast, compact and reliable on the equipment available. For its era, it was the right tool.
But that era is over. The tone-over-telephone constraint that shaped the format stopped binding anyone 2 decades ago. We now move these signals over IP and cellular networks with effectively unlimited capacity. Yet the thing we move is still the same tiny numeric message designed for a phone line in 1985. We upgraded the pipe and told ourselves we had upgraded the protocol. We had not.
The Flaw At The Heart Of Alarm Communications
The real trouble with Contact ID is conceptual, not a matter of speed or capacity.
Contact ID describes an alarm event with an event code. That single code is asked to express 2 completely different things about an alarm point at once – the use of the point and the condition it is reporting.
The use of an alarm point is what it is for, such as a holdup button, medical pendant, fire detector or burglary point. The condition is what state it is in, such as alarm, restored, trouble, tampered or low battery.
A holdup button can be in alarm, or it can simply have a flat battery – these are 2 separate axes of information. Contact ID collapses them into 1. The event code conflates the use of the alarm point with the condition it is reporting. The only thing the format cleanly separates is the qualifier, new event, restore or still-present, which is really just movement along the condition axis. The use never gets a field of its own. It is smeared across the code table.
The consequence shows up exactly where the 2 axes cross. When a holdup button reports a low battery, the signal arrives as a generic low-battery code with nothing to tie it back to the fact that the affected device is a holdup. This is the heart of it – with a single code field asked to carry 2 independent facts, the 2 become mutually exclusive. The code can name the use or report the condition, but not both. Expressing one forecloses the other.
As a result, you learn that a holdup point is in alarm or that a device has a low battery. But you never learn that this holdup point has a low battery. The relationship between the 2, which is often the operationally important part, must be reconstructed from point programming the signal never actually carried.
In fairness, the event code once had a job that justified this. In the days of CAPS and the flat, limited databases of early monitoring software, there was nowhere to look up what an alarm point was for. The signal had to carry its own meaning because the system receiving it had no relational database in which each point’s description could live. Baking the use of the point into the event code was a reasonable answer to a real limitation.
But that limitation is long gone. Every monitoring platform today runs on a relational database capable of holding the description of each alarm point, keyed to the account and the point that reported it. The description need never be hard-coded into an event code, or into an SIA DCS event type, ever again. The signal only has to say which point and in what condition. The database already holds the rest.
Yet we are still carrying a format whose central feature solves a problem we stopped having decades ago.
In my opinion, the answer is not to start sending human-readable text in the signal. A point number is an opaque key, and that is exactly its virtue. It keeps authority over what a point is, and what response it warrants, in one place. That place is the monitoring centre’s database, where the description and the action that goes with it live together and change together. But if we let identity travel as free text from the site we sever that coupling.
This is not a hypothetical worry. Several protocols, though not Contact ID, already allow a free-text label to ride along with each alarm point, and it is routinely promoted as a feature. The operator sees a friendly name instead of a bare number, straight from the panel. But a label the field can set is a label the field can change, and the response plan at the centre does not move with it.
Picture a PIR in an office quietly relabelled ‘Holdup Button’ at the panel, with no corresponding change to the response plan at the centre. The signal now asserts a critical function the monitoring centre never agreed to and is not configured to action.
Just as dangerous is the reverse: a genuinely critical point textually downgraded to something an operator will wave through. The field must say which point fired and in what condition. What that point is, and what happens next, is the monitoring centre’s decision, not an instruction from the site. The point number keeps that line where it belongs.
What all this means is that free text in the signal is not a feature but a vulnerability. It relocates authority over what an alarm means to the panel on the wall, the most physically exposed and least controlled link in the chain, where anyone who can reach the keypad can change how a signal will be read, with nothing at the centre to catch it.
I would argue that identity and meaning of alarm events belongs behind the monitoring centre’s door, not at the point of attack.
30 Years Of Working Around It
Once you see this flaw, the familiar frustrations of the format start to look like symptoms of the flaw. Because the code table is fixed and centrally controlled, a manufacturer with something new to say has nowhere to say it. So they improvise. Manufacturers repurpose general-purpose codes, map their own richer internal events onto whichever standard code is closest, or tuck meaning into the point and group fields.
The result is the dialects every operator knows: the same nominal code meaning subtly different things depending on which panel sent it, and receivers carrying per-manufacturer knowledge to interpret traffic correctly.
A common language that requires you to know who is speaking before you can be sure what they mean is not quite the common language it claims to be.
The message is also impoverished in the context it can carry, and here, unlike the point description, the poverty is real. Carrying the point’s identity as a number is right. Carrying nothing about the event itself is not.
There is no room for the event’s own timestamp, a sensor reading or a confidence value, and certainly none for the verification image or video clip that modern alarm handling increasingly depends on. The event time, in practice, is stamped by the receiver when the signal lands rather than by the panel when the event happened, so the record reflects network timing rather than reality.
When you think about Contact ID as a technology signal integrity and security were never part of the model. Later IP transports added encryption to the pipe, but the message travelling through it is unchanged.
The Conditions We Never Thought To Name
There is a second kind of inextensibility, and technology has made it urgent. It’s not only the use of a point that the format struggles to express. The vocabulary of conditions is frozen too, and it was frozen in an era when an alarm point was a pair of wires or a simple detector.
Alarm, restore, trouble, tamper, low battery. That short list was adequate when that was all a point could be. But alarm points are not that anymore. A point today is very often a networked device, and a networked device can be offline. That is one of the most operationally important things a monitoring centre can know, and it barely existed as a concept when the code table was written.
Worse, the format has no clean, first-class way to say it. “We have stopped hearing from this point” – instead this is inferred from the absence of signals, rather than reported as a condition in its own right.
And increasingly an alarm point is a camera, which brings a whole family of conditions Contact ID never had to the table. A camera’s view can be obstructed, blocked, defocused, blinded by light, sprayed over or turned to face a wall.
View blocked is a genuine, actionable alarm condition, and there is simply no place for it in a vocabulary written before cameras were alarm points. Instead the event is forced to masquerade as a generic trouble or tamper, and the operator loses precisely the specificity that would tell them what is actually wrong.
The lesson is the same as before but angled the other way in this case. The condition axis needs to be as open-ended as the use axis, because the devices we monitor keep acquiring new ways not to function. A format whose list of conditions cannot grow will always be a technology generation behind the equipment it is meant to describe.
Hundreds Of Codes But No Global Fluency
Coming at this from the point of view of a monitoring station it’s the Wild West out there for event codes. Contact ID defines more than 200 of them and SIA DCS describes more than 300. There is no shortage of codes. The trouble is that many are cryptic, and nobody confronted with them is truly fluent in the whole set. Certainly not the client whose premises raised the signal, not the operator in the monitoring centre watching that event signal land, and not the installer who programmed the panel in the first place.
When the 3 parties to an alarm each hold a partial, and slightly different, understanding of what a code means, the result is confusion at precisely the wrong moment. A serious event arrives wearing an obscure number, and the people who must act on it are left interpreting it on the fly, or worse, passing the buck, each quietly assuming someone else understood what they did not.
A reporting language its own users cannot reliably read is a liability not a standard.
SIA Is The Same Model Wearing A Nicer Suit
It’s tempting to think the SIA DC-03 format, DCS, with its readable 2-letter codes, solves the issues with Contact ID but it does not.
Sure, the codes are friendlier to read, and the format carries more text, but each code still fuses use and condition into a single token: BA for burglary alarm, FA for fire alarm, HA for holdup alarm, etc.
Worse, the codes look as though they decompose, with a first letter that often signals the use and a second that often signals the condition. But that pattern is just a memory aid, not a guarantee of event recognition in the field, and enough codes break it that you cannot safely rely on your monitoring station’s interpretation of it.
And the move to IP did not change the story – it ratified it. SIA DC-09, which is the modern standard for reporting alarms over the internet, is essentially just an envelope, a transport that wraps an alarm signal payload in one of 2 formats.
One is SIA DCS, the 2-letter format just described. The other is ADM-CID, Ademco Contact ID, carried over for 1 reason only: the sheer ubiquity of Contact ID.
What this means is that the industry’s own IP-era standard bent ovcer backwards to keep transmitting a 1980s message wrapped in TLS and delivered faster over digital networks. But byte-for-byte it’s the same conflated code underneath.
Contact ID Has Served Its Time
None of this is a complaint about the people who built Contact ID or the panels and centres that run it. It was an excellent answer to the question the 1980s were asking. The problem is that we are still giving 1980s answers to the questions of 2026.
Why are we doing this when we now have the bandwidth to say exactly what we mean – to report what an alarm point is for and the condition it is in as 2 separate, unambiguous facts. Now we can carry time, context and media with an event – now we can let a format evolve without breaking what came before. The technology to do all of this has been sitting in our hands for years.
The trouble with Contact ID is not that it was bad. It is that it was good enough for long enough that we stopped asking whether we could create something better. In my opinion we can and in the interests of efficiency and operational security it’s long past time that we did. Contact ID has well and truly reached end of life.
More detail about BENS Monitoring here and you can read more SEN news here.
“The Problem With Contact ID In The Digital Age.”
