1) Availability. As of this writing, there are remarkably few publically accessible CAP feeds. As time goes by, more and more governments and companies should gravitate towards the standard.

2) Scalability. By their very nature, emergency messaging systems are vulnerable to the Slashdot Effect because as soon as a message is posted, all recipients require it immediately. This can place a high load on the CAP server and stress its available burst bandwidth. Any reduction in QoS will introduce delays that diminish the value of the message. An alternative would be to push out the message via satellite multicast, however, usually multicast providers allow you only a certain window of time each day. If your emergency does not fall within your provider’s multicast window, it will be irrelevant by the time it is delivered.

3) Security. Network operators typically want emergency messages to preempt the regular schedule and/or preempt the entire display by going fullscreen. That requirement makes it a very dangerous feature because it introduces a means to easily hijack a digital sign. This is compounded by the fact that CAP is typically disseminated over regular HTTP which is vulnerable to all kinds of man-in-the-middle and DNS-based attacks. Using HTTPS and enforcing verification of the server’s certificate on the client side would go a long way to mitigate this risk, however, CAP providers really aren’t thinking about security yet, they seem to be more in the proof-of-concept phase.