“PacketCable 电子监控规范”显示，安全传输模式由 CMTS 执行，而不是由 PC 或 IP 电话 (IPP)等端点执行。但是，目前 VoP 市场上的安全性大多数实施于端点上，且其中大部分为隧道模式，因此 PacketCable 必须处理这种安全架构。
前面各部分中列出的 CALEA 面临的其它安全问题同样也是 PacketCable 的问题。
解决方案 为了解决 CALEA 的安全问题，CALEA 截取盒必须在 SA 建立的初期截取发自目标设备的数据包，以获得所需的密钥以及其它安全参数。在哪里进行截取取决于以下诸多因素：NAT、动态主机配置协议 (DHCP)、VPN/安全端点等。
如果 VPN/安全端点为 PC 或 IPP，则端点如何获得 IP 地址非常重要。如果端点 IP 地址通过动态主机配置协议 (DHCP) 获得，则不存在 NAT，截取可在任何设备中进行。但是，来自相同设备的数据包可能选择不同的路由，因此，我们最好在数据包选择另一路径前（通常是从 CMTS 到因特网）截取数据包。
有 NAT 时，最好的截取处就是 NAT 功能所在的地方。正如“PacketCable 电子监控规范”定义的一样，这常常是 MTA，而不是 CMTS。但是，NAT 也可能在 CMTS 上。NAT 单元将专用 IP 地址映射到公用 IP 地址上，反之亦然，因此数据包应在执行 NAT 之前在 LAN 站点上截取。否则，截取盒就要在相同公用 IP 地址的混合消息流中进行数据包过滤。此外，NAT 单元带有应用算法 (ALG)，可处理专用的转换功能。例如，最初传送进来的 SIP 呼叫只有公用 IP 地址。NAT 单元如何知道应该映射到哪个专用 IP 地址呢？它必须运行 SIP ALG，其以 SIP 消息中的用户 ID（如alice@wonderlane.com）或报头中的 CallerID 来查找 Alice 的专用 IP 地址。请注意，Alice 必须已经以她专用的 IP 地址及其姓名和/或 CallerID 在 NAT 器件上注册。
一旦 CALEA 截取盒能够截取目标设备的数据包，则其应设法获得 SA建立消息。如果安全机制不是基于标准协议之上，则执法人员解释安全消息以及随后进行 SA 消息与媒体数据包的解密就会面临很大的困难。如果安全消息基于标准协议之上，则 CALEA 截取盒应该可从 SA 建立消息计算出密钥、密钥大小以及加密方法。
美国 TIA 发布了一系列 PSTN 中 CALEA 的消息格式。由于因特网的架构、协议集、消息格式与呼叫流程 (call flow) 完全不同，因此 TIA 必须发布因特网 CALEA 传输的全新系列规范。PacketCable 规范可作为子集，事实上 TIA 也提到了这些情况。但是，PacketCable 安全规范与 PacketCable 电子监控的修改必须满足许多 VoP 安全要求。此外，尽管原理相同，非基于线缆的 VoP 安全解决方案应在 PacketCable 规范外另行规定。
