Your smart plug stops responding one morning. Your code hasn't changed. TP-Link pushed a firmware update overnight that swapped the device's communication protocol, and now the only way back in is a toggle buried in the Tapo app labeled "Third-Party Compatibility." This has happened three times in three years, and the pattern is always the same: a security vulnerability surfaces, TP-Link patches it by replacing the protocol entirely, and every third-party client breaks without warning or documentation. The developer behind tapo, an unofficial Rust and Python client for TP-Link Tapo devices, has spent nearly four months reverse-engineering the latest protocol change — TPAP — and shipped support in v0.11.1. The result: the Third-Party Compatibility switch can now stay off, which is actually the more secure configuration. TPAP uses SPAKE2+ (RFC 9383) for password-authenticated key exchange, meaning recorded login sessions are useless for offline password guessing and past traffic stays encrypted even if credentials are later compromised. The old KLAP protocol that the toggle re-enables is strictly weaker. The timeline of TP-Link's protocol changes reads like a case study in how incumbents handle third-party ecosystems. In 2023, researchers from the University of Catania and Royal Holloway reported four vulnerabilities in the Tapo L530E bulb's protocol. TP-Link silently swapped AES for KLAP across lights and plugs without announcement. A forum thread asking "Is this intentional?" was locked without answer. In 2024, a Home Assistant camera integration maintainer reported a vulnerability, built a workaround, and asked TP-Link for permission to release it. TP-Link reviewed the code, said no, and eight months later shipped the Third-Party Compatibility toggle instead. In 2025, firmware 1.4.0 brought TPAP to plugs, followed by lights in 2026. The structural dynamic here is worth naming plainly. TP-Link frames Third-Party Compatibility as a security feature — "disabled by default to ensure security" — but turning it on actually downgrades security by reverting to the weaker KLAP protocol. The secure path is TPAP, which TP-Link never documented and made no effort to share with third-party developers. When users asked about Home Assistant support on TP-Link's forums, the response was that Home Assistant "is not an officially supported third-party platform for Tapo products." The security framing provides cover for what is functionally a platform lock-in mechanism. The library update goes beyond protocol support. Version 0.10.0 added handlers for H200 and H500 camera hubs, including the ability to list paired cameras, query recording dates, and download MPEG-TS clips. Plug schedules and timers — features the Tapo app has had "since forever" — are now accessible programmatically. Both were community contributions, and the hub support required roughly thirty rounds of testing by a contributor with physical hardware the library author doesn't own. What makes this story structurally interesting is that the third-party developer is now shipping the better security posture. SPAKE2+ resists offline dictionary attacks and provides forward secrecy — properties the vendor's own "compatible" mode lacks. TP-Link's undocumented protocol turns out to be good engineering wrapped in bad ecosystem behavior. The developer community did the work of making the secure option accessible, for free, with no cooperation from the vendor. The pattern is familiar across IoT: vendors treat local API access as a liability rather than a feature, use security language to justify ecosystem closure, and leave the actual security work to unpaid researchers and open-source maintainers. Nine GitHub issues told the same story of silently broken integrations. The fact that a single developer with community testers can reverse-engineer and ship protocol support faster than a corporation can document its own API says something about where the real engineering capacity sits in this market.
