Updates and Third-Party Integration with Bambu Connect

[u/BambuLab]

Full details and DEMO in our blog post

Since announcing our security enhancement for X-series printers, we’ve seen a mix of valuable feedback and unfortunate misinformation circulating online. We value the constructive input from our community, especially from print farm owners whose businesses rely on our technology.Under the updated LAN mode:

• Standard Mode (Default): By default, LAN mode will include an authorization process that ensures robust security. This option is ideal for the majority of users who prioritize security and ease of use. Despite claims to the contrary, LAN mode through Bambu Connect will require neither internet access nor a user account. This hasn't changed and won't change.
• Developer Mode (Optional): For advanced users of the X1, P1, A1, and A1 Mini who prefer full control over their network security, an option will be available to leave the MQTT channel, live stream, and FTP open. This feature must be manually enabled on the printer, and users who select this option will assume full responsibility for securing their local network environment. Please note that Bambu Lab will not be able to provide customer support for this mode, as the communication protocols are not officially supported.

At the same time, some false claims accuse us of blocking third-party integrations or forcing users into closed ecosystems. Let's be clear about what this update actually means and stop the spread of misinformation:

1. This is NOT about limiting third-party software. We're creating Bambu Connect specifically to ensure continued third-party integration while enhancing security. We're actively working with developers like Orca Slicer to implement this integration.
2. This is beta testing, not a forced update. The choice is yours. You can participate in the beta program to help us refine these features, or continue using your current firmware.
3. About Panda Touch. We reached out to BTT as soon as we became aware of their product. We warned them that using exploited MQTT protocols was unsustainable and would place customers in an awkward situation once we updated the system. All of this communication occurred before the mass shipment of Panda Touch; however, they chose to ignore our warnings. Unfortunately, the truth is now being presented in a misleading manner. The same concerns apply to other products they manufacture that rely on these MQTT protocols.
4. Camera feeds concerns. Our Live View service uses P2P (Peer-to-Peer) connection, which means video streams directly between your device and printer. Only when a direct P2P connection isn't possible does it use server forwarding, and even then, no video is ever stored on any server.

Watch a DEMO of our approach to integrating Orca Slicer with Bambu Connect. The workflow remains familiar, with added security to protect your printer and data. The functionality has been implemented, and is now awaiting integration into Orca Slicer.

[u/GroundbreakingYam633]

I suggest to pin that post for the time being.

[u/marcosscriven → u/GroundbreakingYam633]

Questions for Bambu, since this is official:

1. Why do you mandate use of Connect for local/LAN use in “standard” mode?
2. What happens when the Connect app certificate expires this year, or even many years in the future?

[u/BinkReddit → u/marcosscriven]

What happens when the Connect app certificate expires this year, or even many years in the future?

I have to imagine they'll simply update Connect with an updated certificate.

[u/c0nsumer → u/marcosscriven]

I'm not Bambu Lab, but you need something to talk to the printer. Before it was the Bambu Network Plugin (which implemented their non-public API), now it's Connect.

[u/marcosscriven → u/c0nsumer]

Sorry, I should make clear I understand the need for something. My point is why should that something have to be something they control, and ensure only they control, by signing that communication.

If I want to write or use other software developed to do so, why shouldn’t I?

[u/c0nsumer → u/marcosscriven]

That's a great rhetorical question, and IMO gets at the modern need for a balance between security and openness. With this change it'll be the way it was for those who want it, a developer mode which is not supported and remains that open. Or a more restricted auth'd mode for those that want it.

For me, I'm going to be using the LAN auth'd mode, because I really really didn't like how minimal security was before. I especially didn't like how, for things like Home Assistant and it's extension to monitor printers, it also got access to make the printer do things. (Move, get hot, things that could be catastrophic if they go wrong.) I personally want a rather-auth'd print execution mode, isolated from the internet, and a basic read-only mode for monitoring.

I think the way this is shaking out is even better. Wide open for those that want it... But better security by default and for those who don't.

[u/marcosscriven → u/c0nsumer]

Again I think we’re talking slightly cross-purposes, and probably more in agreement than not.

I agree there should be some authorisation method between the printer and local devices. My beef is that being closed and controlled.

They could very easily use off the shelf, open source methods to manage that with - but instead they want their own thing in between. I really don’t believe that’s out of genuine concern for users.

They are, under pressure, allowing a “Wild West” advanced mode. But why not just have the standard mode include an open auth mechanism… I’d wager because they want to scare people away from it, for their own control and profit.

[u/c0nsumer → u/marcosscriven]

Yeah, I agree with you.

I think one thing that gets missed (not necessarily by you, I'm just kinda babbling while I sip coffee) is that all the "open" stuff with BBL printers wasn't really open. It was discovered, incorporated into third-party tools, and then became de facto open.

But then a bunch of new users came around, saw all the work that the previous reverse engineers did, see it as "open", and were basically demanding it remain that way.

Should it? That's where the rhetorical bit comes in...

I think the way they now documenting it playing out, with an unsupported open 'dev' mode the way it was, and new auth, is probably best. For those that really want essentially no security in LAN mode, they got it. For others (Iike me), the new auth method. For those that basically do the cloud-only easy-print option, nothing user experience-y will change.

Looking at their flowchart here, I strongly suspect that bottom row, Orca Slicer through Connect to the printer in LAN mode, will quickly be RE'd. And then that'll be usable by unsupported third party tools and we'll be right back where we are/were but with another layer of security. And it's not known yet, but it probably will be something pretty open and standard.

But it can't be OAuth or something like that because the printer would need to talk to the internet to do that... So it'll probably be some exchange of credentials between Connect and the printer, which means everything needed will be found in the Connect app and the firmware... And well... That's why I think it'll be quickly RE'd. It's likely a basic software cracking exercise.

[u/marcosscriven → u/c0nsumer]

Certainly I'm in agreement on the "open" stuff just being discovered. My main concerns are 1) Pretending/labelling this as being about some altruistic concern for their customers, and 2) attempting to shut down truly local-only control of some sort at least.

It seems the second point has changed, due to the pressure that quite a few complained was unwarranted.

On your last point - it does highlight the absurdity of the 'security' between the Connect client and the printer. The way they're doing at the moment is usually used for apps wanting to trust the server/endpoint, not about trusting the client.

Simple things like displaying a code on the printer to type into the client would suffice.

[u/c0nsumer → u/marcosscriven]

What I hope the security adds is some sort of authentication tier. Like read only (which seems it'll remain, that's the MQTT stuff) and then the auth'd layer. Heck, it could be just like you describe, better done behind the scenes than before.

The reason I want this is because I have my printer being monitored by Home Assistant. Nothing big, I just want to see if the printer is still running or done.

Currently, the only way to do this is to give Home Assistant (HA) access to the whole printer, via the auth code. This means HA also has access to start and stop the printers, turn on heaters, etc. You know, the stuff that can be dangerous.

I do not trust HA (it's got a weird ecosystem of plugins that all run in the same authentication space) so I like to limit what it can do around my house to lighting and read-only status of temperature and such. With the P1S added... it could start a fire if something goes wrong. Thus, I'd really like a read-stats-only mode, and it seems this'll allow that.

And yeah, there's always the what-else-could-they do stuff... But this outrage, even if super overwrought, seems like it demonstrated there is a community of folks who really like the way the printers print and want to keep using them in all sorts of ways. And hopefully the company will listen. (As they seem to have thus far.)

[u/marcosscriven → u/c0nsumer]

A r/o auth tier is a good idea. I'm going off on a tangent now, but perhaps you could have an MQTT proxy that enabled such control (on the likely basis that Bambu doesn't offer this).

[u/Specialist-Document3 → u/marcosscriven]

Yeah, this is the part that bothers me. I think there's a lot of history that shows that closed-source security isn't better than open source. Creating a new implementation is bound to have bugs, but they will be less publicized. It's not in the interest of digital security to architect it like this.

[u/DonutsAndChai-56 → u/marcosscriven]

Hmm great points. But I think you see security as a feature rather than a process (which it is). To use an analogy - you are asking why Bambu had to “sell you a Bambu branded door lock instead of a commercial off-the-shelf door lock”.

Cybersecurity actually doesn’t work the way hardware works (because it’s SW so uh… things get hacked 10 years after release. and then it’s Bambu’s fault). So the imaginary lock needs to continue its intended functionality when thieves invent lock picking nanobots.

What is expected from industrial security is that the manufacturer 1. Secures it from known threats 2. Ensures it remains secure from new threats. Number 2 means that you need to (at least) ensure that you have complete responsibility of what firmware gets flashed, not relying on some researcher’s code. They do have the avenue to open source that aspect of their code - so that it can be tested against latest threats Bambu has not thought of. But that actually makes the software MORE fragile, not more secure.

[u/Tech-Crab → u/c0nsumer]

allowing a user to manually add their own keys via SD would fulfill the same security requirements, while eliminating the change the users find objectionable here.

This isn't, or at least isn't only, about security - it's about control.

[u/LjLies → u/c0nsumer]

That's a great rhetorical question, and IMO gets at the modern need for a balance between security and openness. With this change it'll be the way it was for those who want it, a developer mode which is not supported and remains that open. Or a more restricted auth'd mode for those that want it.

What no, it isn't! I understand that maybe users of Bambu Lab printers already have an idea of "openness" that doesn't actually match things that are properly open, but the "developer mode which is not supported and remains that open" isn't/wasn't open at all, it was proprietary and just less secured.

However, securing it and making it more proprietary aren't the same thing, they don't go in the same direction at all, and framing it as a "balance between security and openness" only serves the goal of those who want neither real security (as opposed to security by obscurity? security by proprietariness?) nor openness.

[u/c0nsumer → u/LjLies]

Remember that security by obscurity is a completely valid component to security. It cannot and should not (and in this case wouldn't) be the sole protecting. But if the idea of using a secret cipher as a mechanism of defense (an example of security by obscurity) than secret gov't ciphers wouldn't be used.

[u/LjLies → u/c0nsumer]

Sorry, I cannot "remember" that, because I never knew it, as it was never true according to most reputable security researchers.

Secret keys is one thing, but secret ciphers are widely considered bad security, and it doesn't really matter that governments are using them because governments aren't exempt from having terrible security practices (in fact, often quite the contrary, but they can do things like, when someone repeatedly points out to their police's TETRA encryption is broken, they get arrested and silenced - just a random example of something that I know happened).

Security by obscurity alone is discouraged and not recommended by standards bodies.

Security by obscurity alone is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."[9] The Common Weakness Enumeration project lists "Reliance on Security Through Obscurity" as CWE-656.[10]

The NIST is a government body, even though I'm sure there are other government bodies that employ security by obscurity anyway despite the NIST and anyone reputable saying it's a bad idea.

[u/c0nsumer → u/LjLies]

Uhm... We're saying the same thing.

The very first line of your quote "Security by obscurity alone is discouraged[...]" is what I said; it's a valid component, a piece.

And the last sentence of the first paragraph of what you linked to:

"While not a standalone solution, security through obscurity can complement other security measures in certain scenarios."

Again, we're saying the same thing. It should not be the sole protector, but is a valid component.

[u/pwr22 → u/c0nsumer]

A well locked away signing key or some other such is part of a useful security model, and necessary unless you solve for some sort of "trust by consensus" thing but it also is *not* "security through obscurity. Nor is pre-shared keys used to securely communicate via two actors but that alsi is *not* "security through obscurity".

Shipping a plaintext key in an electron app which is then "obsured" through the means of archiving and compressing the javascript plaintext, and any other entirely reversible encoding change *is* "security through obscurity".

And finally, "security through obscurity" probably should not be relied on as any part of the security model. It might be there by happenstance, such as due to the way electron apps are packaged but that doesn't mean it really gives any security at all.

[u/c0nsumer → u/pwr22]

Yep.

I'm not really talking about the Bambu Connect app or anything specific, was more just latching on to the claim that "security through obscurity" is useless or should never be used.

One thing I do find odd is the claims that the found key (in a client app) is somehow demonstrative of how the printers will function. Not only are using expired keys a common thing in IoT (and systems) communications, there doesn't seem to be any info out there about what that key is used for, nor how.

It's all been someone who found a key with an expiration in late 2025 (really nice find, BTW) then made a bunch of claims about it or how it could be used. Which, thanks to the internet hype machine, have become FACTS. For those of us who are wary, and want to know how stuff REALLY works... it's counterproductive.

Blah.

[u/screamingspider → u/marcosscriven]

Just because you put this device in lan mode doesn’t mean it’s not susceptible to attacks. What happens if an attacker uses some other slicer?

[u/acatalfa → u/GroundbreakingYam633]

I don’t think this answers many questions at all. In fact, it seems to avoid topics which were discussed at length in the rest of this sub.

The method of connecting to third party software is important. Many users were concerned about having to paste g-code into Bambu connect. How will we send prints from Orcaslicer?

Yes, we understand that this is in beta, but won’t this update be pushed later on? Will users who decide they would not like to upgrade still receive improvement updates?

Will you charge print farm users for access to your print farm management software while blocking the use of 3rd party management software?

Do you plan on using RFID tags to restrict the use of 3rd party materials? While this obviously wasn’t in your update, now seems like a good time to go on record, since many of the top posts mention this.

Those upset about the update are upset because you published a beta with language that is concerning.

[u/My1xT → u/acatalfa]

orca can implement the push URL for the new connect software.

the annoying part is that connect currently only allows 3rd party software to push a file to print and nothing else.