Bambu's Authorization Control now has a legal test case
Bambu Lab’s Authorization Control gates print start, motion, temperature, calibration and firmware updates behind its own authentication path. In April 2026 it became the basis for a cease-and-desist against a fork developer. He had restored direct control on top of AGPL-licensed source, so the licence question now has a real dispute attached.
Key Takeaways
- Authorization Control locks printing, motion, fans, hotend and calibration behind Bambu’s own software.
- Bambu announced the system in January 2025 and called it a security update.
- In April 2026 it became the basis for a legal threat against a fork developer.
- The fork was built on source code Bambu itself publishes under the AGPL.
- Control over a printer you own is now a licence question as well as a policy one.
What the Authorization Control system gates
Bambu Lab announced the change on 16 January 2025. Hackaday’s report put the first X1-series rollout a week later. The company pointed to real printer exploits as its reason, and the risk it names is real for any printer left open to the internet.
The gate covers far more than remote access, as the Consumer Rights Wiki entry records. Each of these needs a Bambu-issued token now, even on your own LAN.
| Gated operation | What it means in practice |
|---|---|
| Print initiation | Sending a job to the printer, over the local network or the cloud |
| Motion control | Jogging the head or bed from software |
| Fan and hotend control | Setting temperatures and cooling from outside the printer’s own menu |
| AMS configuration | Telling the filament changer which spool holds what |
| Calibration | Running bed levelling and flow routines remotely |
| Remote video | Watching the built-in camera from a third-party app |
| Firmware upgrade | Flashing anything to the machine |
You can still walk up to the printer and start a job from an SD card without a token. The printer also keeps reporting its status, so a progress readout in Home Assistant survives. Anything past reading a number needs Bambu’s own client.
For third-party slicers, that client is Bambu Connect , a closed-source middleware layer. It takes a URL command with a file path, a name and a version, and nothing else. A slicer can hand over a file and ask for a print. It cannot touch temperature, motion or the AMS. Accessory makers came off worse: Big Tree Tech told owners of its Panda Touch controller to stop updating firmware, because the next update would break the device for good.
The timeline, dated
- 16 January 2025. Bambu publishes “Firmware Update: Introducing the New Authorization Control System” and describes the gated model. An FAQ entry reassuring owners that older firmware keeps working appeared later, not on the day.
- Early 2025. The X1 rollout lands, then the P-series and A-series updates follow. 3D Printing Industry reported the backlash, a “Developer Mode” concession, and a public jab from Prusa Research chief Josef Prusa. OrcaSlicer maintainer SoftFever refused to adopt Bambu Connect at all.
- Through 2025. Owners find ways around the gate: staying on old firmware, blocking the printer’s internet access, or running the X1Plus custom firmware. A few rip out the control board.
- 23 April 2026. Polish developer Paweł Jarczak publishes a fork called OrcaSlicer-bambulab. It restores direct network printing to Bambu machines. He builds it on Bambu’s published source plus his own glue code, and ships no Bambu binaries.
- Late April 2026. Bambu contacts Jarczak privately on Reddit and demands the fork come down. A cease-and-desist letter has been prepared, the company says. He wipes the repository the same day. Tom’s Hardware covered the takedown and so did XDA .
- 7 May 2026. Bambu publishes “Setting the record straight on Cloud Access and Community” . The post recasts the fight as one about cloud access and impersonation. Jarczak replies in the r/BambuLab thread the same day.
- 9 May 2026. Right-to-repair campaigner Louis Rossmann pledges $10,000 toward Jarczak’s legal defence if Bambu sues. Tom’s Hardware reported the pledge the following day.
Jarczak took the repository down but refused to concede the argument. His public archive notice calls the removal a practical choice, and says nobody should read it as agreement with the claims against the project.
What does the AGPL require here?
What follows is a plain reading of published licence terms and public statements. It is not legal advice. No court has decided any of it.
Bambu Studio, the company’s own slicer, ships under the AGPL-3.0 , and it has no choice about that. The program comes from PrusaSlicer, which came from Slic3r, and the licence follows the code downstream. Copyleft is the whole point of the AGPL. Anyone who gets the code may use it, change it and pass it on. The catch is that they hand the same rights to everyone they pass it to.
Section 10 of the licence is the clause the dispute keeps circling.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.
Section 7 goes further. It lists the only extra terms a licensor may bolt on. Anything outside that list, a recipient may strip out. Meanwhile Bambu’s Terms of Use bars users from changing, copying, reverse engineering or publishing “the Product.” That is section 3.4. Section 3.5 bars bypassing any rights system inside it. Both documents sit on the same company’s servers and point opposite ways.
Bambu’s May blog post narrowed its own claim.
Our cloud is a private service. Access to it is governed by a user agreement, not the AGPL license.
The same post grants that anyone may take the code, change it and hand it on, with no permission from Bambu. So the company concedes the fork itself. What’s left is the HTTP User-Agent string the fork sent to Bambu’s cloud. The post called that string faked identity data. It is built in src/slic3r/Utils/Http.cpp from constants in version.inc. Both files sit inside Bambu’s own AGPL repository. So a clean build of plain Bambu Studio calls itself BambuStudio on every request, because Bambu wrote that value.
User-Agent is not authentication. It is just self-declared client metadata. Any program can set any User-Agent. And the most important part: this comes directly from your own AGPL code.
Most arguments about this merge three separate things:
- The licence on the source. The AGPL governs Bambu Studio’s code and grants the right to change it and pass it on.
- The terms on the cloud. A private service can set conditions for connecting to it. Bambu argues those conditions sit in a contract, not in the licence.
- The ownership of the machine. You bought the printer. Neither document transfers it back.
The letter was never published. No primary source shows which law Bambu invoked, or whether it invoked one at all. A demand letter is only a claim, and nobody has taken the argument to a judge.
What this means if you own one of these printers
Say you print from Bambu Studio or the Handy app, with the printer signed into the cloud. Nothing about your day changes.
Everyone else picks up the friction. LAN-only owners still print locally. Their jobs now pass through Bambu Connect rather than straight from the slicer. Third-party slicer users export and import instead of hitting one button. Print farms lose the hooks they built fleets around, and home setups drop from control down to a progress bar.
Before you buy any connected machine, ask what it does the day the vendor’s service stops. Does it work with no account? Is there a documented local API? Does the maker publish firmware you can flash yourself? A printer that answers no three times is closer to a rental than a purchase. Rivals are chasing those buyers with hardware instead of accounts, and Creality’s quick-swap nozzle system is the loudest example this year.