Bambu Lab - Setting the Record Straight About Our Security Update
Bambu Lab’s plan to route 3D printer control through its proprietary Bambu Connect software, tightening access to the existing LAN/MQTT interface and third‑party tools, is being read by many as vendor lock‑in dressed up as a “security update.” Commenters debate whether mutual TLS and a controlled client are genuinely needed to satisfy corporate security requirements or mainly serve to sideline open‑source slicers and accessories such as OrcaSlicer and Panda Touch. While some note that printers can still run offline in LAN or new “developer” mode, many feel trust has been damaged and are reconsidering future purchases or looking to alternatives like Prusa.
Scope of the change and “developer mode”
- Update introduces Bambu Connect with mutual TLS, a “developer mode,” and SD-card firmware updates.
- Several see “developer mode” as just preserving the current LAN behavior but marked as insecure/unsupported, and fear it could be removed later.
- Others see it as a meaningful rollback from the earlier, more restrictive proposal that would have required a vendor shim and embedded cert even for LAN use.
LAN mode, cloud dependence, and ownership
- Some state printers work fully offline in LAN mode (and even initial setup) with SD-card firmware; others assert setup still requires app/cloud. This remains unclear.
- LAN mode currently loses features like camera access, timelapses, and some spool/RFID functionality, which is viewed as an intentional cloud push.
- Strong sentiment that hardware should remain fully usable without any cloud tie-in; “developer mode” is seen by some as an unacceptable compromise.
Security rationale vs. lock‑in concerns
- Defenders argue FTP and (earlier) non‑TLS MQTT are weak for corporate networks; mTLS via a controlled client is called standard practice and needed for enterprise sales and audits.
- Critics counter that MQTT over TLS with proper auth is widely used and sufficient, and that Bambu’s design conflates security with vendor control.
- The DDOS incident on Bambu’s cloud MQTT from faulty third‑party clients is cited; skeptics note mTLS and client lock‑in won’t stop determined attackers or materially reduce DDOS load.
- Hard‑coded/embedded certificates and ToS language about blocking printing until “critical” updates are accepted raise fears of remote bricking and time‑limited hardware.
Impact on third‑party tools and ecosystem
- New model pushes third‑party slicers (e.g., OrcaSlicer) and controllers (e.g., Panda Touch–like devices) to go through Bambu Connect instead of direct MQTT/FTP.
- Some see this as reasonable API stewardship and security hygiene; others view it as predatory lock‑in and an attempt to kill independent ecosystem products and farm automation tools.
Brand trust, community reaction, and alternatives
- Many praise Bambu’s hardware and UX but say this move significantly erodes trust and will affect recommendations and purchase plans.
- Several point to broader patterns of “enshittification” and recurring‑revenue plays, arguing market forces won’t prevent future subscription or feature paywalls; regulation is proposed as necessary.
- Alternatives like Prusa and upcoming Core One are discussed, but acknowledged as more expensive, less feature‑rich, or also drifting away from open source.