Not a lawyer, but I went through this with a test lab for a BLE product. The modular grant covers the radio as long as you stay inside it: same antenna type and gain, no changes to output power, frequencies or modulation, and the module’s FCC ID shown on your label (« Contains FCC ID … »). Updating your own application code doesn’t touch that. The host product still needs its own unintentional-emitter check (Part 15B), once, not per update. Ask your lab to put that in writing for your file, it’s a short email for them.
Where you could break the grant is if an update ever lets the radio config change, so lock that: the app should have no command or setting that changes bands or power.
On the Hermetry side, what I’d set up before the first real rollout:
- Register your signing public key under Firmware > Signing keys and keep « Allow unsigned images » off on the tracker profile. Only an owner can add keys, and the device must refuse an image whose signature doesn’t verify, so build that check into your bootloader.
- Fill in Hardware models on each upload, so a rev B image never goes to rev A boards.
- Use Send in waves on the profile assignment, start with your own 10 test trackers.
- Leave « Allow updates over LTE » off until you know the image size and your data plan, otherwise each tracker downloads it on cellular the moment it’s assigned.
- Report
current_fw_versionafter every connect. Hermetry only marks an update done when the new version actually shows up, and flags it if the old one comes back.
All on Firmware updates (OTA).

