Have a project in mind? Let's talk.
ESP32 secure provisioning is the process of giving a device its network configuration without turning setup into an open door. Espressif's unified provisioning framework supports Wi-Fi credentials and custom configuration over transports such as Bluetooth LE and SoftAP with an HTTP server. It separates transport choice from application-level security, so choosing BLE or a temporary Wi-Fi network is not the whole security decision. Espressif unified provisioning
For a connected product, onboarding also has operational consequences: who can configure the device, where its setup secret comes from, how it behaves after a failed attempt and what happens when ownership changes. This guide explains the documented ESP-IDF mechanisms, then adds our own production checklist. It is not a claim that Codesprint has manufactured or tested a particular device fleet.
Espressif identifies three security concerns for provisioning: protecting exchanged configuration, authenticating the device to the client and using proof of possession where appropriate. Its guide describes PoP as a unique per-device secret supplied to the provisioning client to help ensure that the person configuring the device possesses it. These are more specific requirements than simply discovering a device with the expected name. Espressif unified provisioning
Our product checklist separates network configuration, device identity and cloud-account ownership. Network setup answers which access point the device should join. Device authentication answers which device the client is talking to. Cloud ownership answers which customer may control it through your backend. Completing one step should not silently count as permission for every other step.
For example, a successful Wi-Fi connection does not by itself prove that a device belongs to a particular customer account. Our recommendation is to define the backend claim or enrollment flow separately, including the evidence required to bind the physical unit to the account. Keep that decision explicit when an AI-generated mobile app or backend connects several onboarding steps together.
The unified provisioning guide supports SoftAP plus HTTP and Bluetooth LE using GATT. It notes practical SoftAP tradeoffs: the phone leaves its existing access point, and the device uses the same radio while hosting its setup network and connecting to the target network. Different channels can make connection-status updates unreliable. The guide also describes platform-specific connection constraints on iOS. Espressif unified provisioning
Our transport review asks where installation happens and who performs it. A consumer with one phone, a technician installing many units and a product with limited memory have different constraints. Test the actual phone operating systems, board variant and deployment network. A desktop script successfully reaching a provisioning endpoint is not evidence that the customer's mobile flow works.
Do not use transport convenience as a substitute for authentication. Espressif distinguishes transport security from application security and asks developers to assess what the transport actually provides. It describes a unique WPA2 SoftAP passphrase as one possible possession factor and discusses application-level protection when transport security is absent or insufficient. Espressif unified provisioning
The documented schemes are distinct. Security 0 provides no encryption. Security 1 uses Curve25519-based key exchange and AES-CTR, with an authorized PoP mode or a no-auth mode using null PoP. Security 2 uses SRP6a-based key derivation with AES-GCM encryption. An encrypted session with no possession authentication should not be described as equivalent to a session authenticated with a device-specific secret. Espressif unified provisioning
The current development-branch protocomm documentation recommends Security 2 for production and says Security 0 should not be used there. It also notes that supported schemes are controlled through configuration and that enabling several increases firmware size. Because this is development-branch guidance, check the options and supported client behavior in the exact ESP-IDF and provisioning-component versions you ship. Source
Our release requirement is evidence of the selected scheme on both ends, not just a firmware constant. Confirm that the phone application establishes the expected session and that wrong credentials fail. Do not add a silent fallback to Security 0 or unauthenticated setup to make a troublesome device appear easier to onboard. Fail visibly and preserve a supported recovery route.
The ESP-IDF 6.0 migration guide says wifi_provisioning moved out of ESP-IDF into the separate network_provisioning component, with several APIs renamed. It also lists changed defaults for Security 0 and Security 1 support. Our recommendation is to pin compatible firmware and client versions, review the migration notes, and test the actual configuration instead of copying defaults from a different documentation branch. Espressif provisioning migration
For Security 2, Espressif says the salt and verifier are generated beforehand using an identifying username and password, then stored on the ESP32. The username and password must reach the provisioning client through an appropriate mechanism, such as a QR-code sticker. Those values and the verifier are not interchangeable fields; the client and device have different roles in the protocol. Espressif unified provisioning
Our manufacturing checklist records how each unit receives its identity and setup material, how duplicates are detected and how the matching label is attached. Avoid treating an example password as a fleet credential. Protect the generation and injection process, limit access to the records, and test that the label for one unit cannot provision another unit by mistake.
A QR code is a delivery mechanism, not automatic proof of secrecy. Our recommendation is to consider who can photograph the label during manufacturing, distribution and use. Decide whether the printed material is a long-lived onboarding factor, how support handles a lost label and what changes during resale. Do not put setup passwords into routine analytics, crash reports or support screenshots.
Espressif's Wi-Fi provisioning tutorial is useful for learning the lifecycle: initialize the components, start provisioning, handle events and connect to the target network. Its example also prints received Wi-Fi credentials and generates setup QR-code data through terminal output. Those are tutorial conveniences to review before using the example in a product. Espressif provisioning tutorial
Our production logging rule is to capture state transitions and error categories without recording passwords, setup secrets or complete credential-bearing payloads. An installer should be able to distinguish an authentication failure from a Wi-Fi connection failure without exposing the customer's network password in a log export. Apply the same review to the phone app and the backend, not only the microcontroller.
The tutorial itself advises stronger authentication, robust PoP management and protection of device identity and credentials for production. Treat example code as a starting point with explicit assumptions, rather than a release-ready security specification. Espressif provisioning tutorial
The tutorial explains that a basic example can restart provisioning on every reboot. It shows checking whether Wi-Fi credentials are already stored in NVS to avoid rerunning the setup flow unnecessarily. A restart, first boot and intentional network reset should not all be treated as the same event in a product. Espressif provisioning tutorial
Our proposed lifecycle has explicit states: unconfigured, provisioning, configured, connection failed and reset requested. Define the physical or authenticated action that reopens setup, a timeout for an abandoned session and the behavior after interrupted setup. A temporary cloud outage should not automatically reopen a local onboarding interface unless that is a deliberate, reviewed product decision.
Reset needs a written contract too. Our recommendation is to distinguish clearing Wi-Fi settings from clearing customer ownership, cloud credentials and user data. Tell the user which reset they performed. Test that an old owner cannot continue controlling the device after a supported ownership transfer, and that a network reset does not accidentally delete data the product promised to retain.
Encrypted transport does not by itself describe storage protection. Espressif's RainMaker security article explains that its agent stores sensitive configuration such as Wi-Fi credentials in device storage and points to NVS encryption for protecting that data. This is a RainMaker architecture example, not evidence that every ESP32 project automatically enables encrypted storage. Espressif RainMaker security
Our checklist verifies the actual firmware configuration and manufacturing procedure for stored secrets. Keep flash encryption, boot verification and provisioning authentication as separate controls with separate evidence. For that foundation, read our ESP32 flash encryption and secure boot guide. For recovery after firmware releases, see our ESP32 OTA rollback guide.
This is our suggested release matrix. Test a wrong setup secret, the right secret for a different device, interrupted radio connectivity, an incorrect Wi-Fi password, an unavailable target network and a power cut before configuration completes. Then repeat with stored configuration, after network reset and after an intended ownership transfer. Check both the device state and what the phone tells the user.
Include two installers or clients attempting setup at the same time. Verify that the app identifies the intended unit and does not report success from a stale status response. Confirm that setup endpoints close when your lifecycle says they should. Record the firmware, client and component versions alongside the results, so a later dependency update can trigger the right regression tests.
For a device-to-cloud product, successful provisioning should be evidence of a specific completed step, not a vague "ready" badge. Our recommendation is to report local network setup, backend enrollment and user access separately. If you need help connecting those layers, use our contact page. This checklist is a focused starting point, not a certification of the whole product.
No transport name establishes the full security design. Espressif separates transport security from application-level security and asks developers to choose protection suited to their use case. Espressif unified provisioning
Espressif describes it as a unique per-device secret supplied to the provisioning client to help authenticate the setup session. Its Security 1 implementation supports a PoP mode; Security 2 uses SRP credentials with salt and verifier on the device. Espressif unified provisioning
The current protocomm development documentation says no: it provides neither encryption nor authentication and recommends Security 2 for production. Verify the matching implementation in your release versions. Espressif protocomm
Our recommendation is to treat these as separate decisions. Network configuration gets the device connected; your account-enrollment design must establish who may control it and how that access is revoked or transferred.
Ready to take the first step towards unlocking opportunities, realizing goals, and embracing innovation? We're here and eager to connect.