# Niimbot B1 Security Review
# Classification: Confidential
# Date: 2026-06-09
# Reviewer: Claude Code (drafted); pending Founder approval
# Status: Draft

---

## 1. Vendor / Device Overview

| Field | Value |
|---|---|
| **Name** | NIIMBOT B1 thermal label printer (Xiamen Gengcon / NIIMBOT) |
| **Website** | niimbot.com |
| **Service / purpose** | Portable BLE thermal label printer (384 px, 203 DPI) |
| **CBB use case** | Print ScopeDOPE DOPE labels. ScopeDOPE drives the printer **directly over BLE using CBB's own driver** (ISSC UART-over-BLE) — the official **NIIMBOT app and NIIMBOT Cloud are NOT used.** |
| **Data tier(s) accessed** | Tier 1–2 — the rasterized label image (ballistic DOPE values) sent to the printer; on-device, offline |
| **Access type** | BLE (ISSC UART-over-BLE); CBB-authored driver; no vendor app, no vendor account, no cloud |
| **Proposed onboarding date** | Already integrated — retrospective review |

> **Key distinction — and a deliberate security decision:** the official **NIIMBOT app uses a "Cloud Printing" service and its store listing discloses that it may share data with third parties.** CBB **does not use the NIIMBOT app or cloud at all.** ScopeDOPE speaks the raw BLE printer protocol directly with a CBB-authored driver, so **no label content, ballistic data, or device data is ever sent to NIIMBOT's cloud or any third party.** This review assesses the **BLE link + physical device**, not the vendor app/cloud (which CBB intentionally bypasses).

---

## 2. Data Exposure Assessment

### 2.1 What CBB data will this vendor / device access?

- The **rasterized label image** sent over BLE for printing — contains the DOPE values the user chose to print (e.g., range/elevation/windage table).
- Printer status/ack frames.

This is sent **locally over BLE to the printer only.** Nothing reaches NIIMBOT or any third party, because the vendor app/cloud are not in the path.

### 2.2 Where will CBB data be stored by this vendor?

**Nowhere off-device.** No NIIMBOT app, no NIIMBOT Cloud, no account. The label image is generated on the phone and streamed to the printer's buffer for the print job; the printer does not persistently store CBB data.

### 2.3 Is any Highly Confidential data (Tier 4) involved?

- [ ] Yes
- [x] **No** — printed DOPE values are user-facing output, not engine internals/SPEC. The DOPE-Blend methodology that *produced* the numbers stays on-device and is never sent to the printer.

---

## 3. Vendor Security Posture (Software vendors only)

**N/A by design.** CBB uses no NIIMBOT software or cloud service, so vendor SaaS data-handling and certifications are **not in the trust path** — this is the explicit reason CBB built its own driver rather than using the vendor app. The only vendor-side dependency is the **device itself** (§4).

> **Documented rationale:** NIIMBOT's app/cloud data-sharing posture (third-party sharing per the app store listing) is precisely why the native-driver approach was chosen. This is a security *strength* of the design, not a gap.

---

## 4. Hardware Security Assessment (Hardware / BLE devices only)

### 4.1 Communication protocol

- **BLE, ISSC UART-over-BLE**, CBB-authored driver.
- Confirmed protocol (project memory): 384 px, 203 DPI; opcodes incl. `END_PAGE=0xE3`, `END_PRINT=0xF3`, 7-byte `START_PRINT`, 6-byte `SET_DIMENSION`.
- **B21 Pro variant:** same protocol family at **300 DPI** (raster generation accounts for the higher resolution; DOPE-33). The B21 Pro should get its own review row when integration lands, but the BLE security posture is identical.
- Data flow is **one-way push** of a label raster + control frames; no CBB data is read back beyond status/ack.

### 4.2 Firmware update mechanism

- Firmware updates (if any) are delivered via the **vendor's app/cloud, which CBB does not use** — so CBB does not perform or depend on printer firmware updates. The printer ships with vendor firmware; CBB treats it as a fixed-function BLE peripheral.
- **Consideration:** because CBB doesn't manage firmware, a device shipped with vendor firmware of unknown provenance is trusted only as a "dumb" label sink. Mitigated by the fact that **no sensitive data is sent** and the link is local BLE.

### 4.3 Data transmission security

- [x] Device does **not** transmit CBB data to any external server (CBB path is BLE-only, offline; vendor cloud bypassed)
- [~] BLE link encryption: label data is pushed over BLE; **confirm whether bonding/encryption is used.** Impact is low — the payload is the user's own DOPE label, printed in their physical presence; a sniffer in BLE range would learn only the label the user is already printing in the open.
- [x] No CBB credentials or persistent data are stored on the printer

### 4.4 Physical security

- If lost/stolen, the printer exposes **no CBB data** — it holds none persistently. Commodity device; replacement cost only.

---

## 5. Integration Security

### 5.1 Credential management

- **No credentials** — the native BLE print path uses no account, key, or token. Nothing to store in Key Vault.

### 5.2 Network exposure

- **None.** No internet path, no inbound rule, no webhook, no public IP. On-device + local BLE only.

### 5.3 Offboarding plan

- Disable/remove the `niimbot_b1` driver path in the app. No vendor account or cloud data to delete (none exists). No third-party offboarding needed.

---

## 6. Risk Summary

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Label data sent to NIIMBOT cloud / third party | **None** | — | Vendor app/cloud not used; CBB-native BLE driver bypasses it entirely (by design) |
| BLE sniffing of label content | L | Negligible | Payload is the user's own DOPE label, printed openly in their presence; no identity/secret |
| Untrusted vendor firmware on device | L | L | Treated as fixed-function BLE sink; no sensitive data sent; no firmware managed by CBB |
| Lost/stolen printer | L | Negligible | No CBB data stored; replacement cost only |

**Overall risk rating:** **Low** — the headline vendor-app/cloud data-sharing risk is **eliminated by design** via the native driver.

**Recommendation:** **Approve with conditions** — pending Founder sign-off.

**Conditions:**
1. Confirm whether the BLE print link uses bonding/encryption (document; low impact regardless).
2. Add a B21 Pro row/sub-review when DOPE-33 integration lands (same BLE posture, 300 DPI).
3. Add Niimbot B1 to the "CBB Risk Register" SharePoint List (hardware entry), noting the native-driver / no-cloud design as the key control.

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (`03_-_Confidential/`) |
| **Location** | `OneDrive/ScopeDOPE/03_-_Confidential/Hardware/Niimbot_B1_Security_Review.md` |
| **Cross-references** | `Security_Review_Template.md`; `scopedope-shared` Niimbot driver docs; `WeatherFlow_Tactical_Security_Review.md`; "CBB Risk Register" SharePoint List |
| **Created** | 2026-06-09 |
| **Last updated** | 2026-06-09 |
| **Next full review due** | 2027-06-09 |

---

## Revision Control Block

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| DRAFT | 2026-06-09 | Claude Code | — | — | Initial draft. Framed around CBB's own native BLE driver (ISSC UART-over-BLE); documents that the NIIMBOT app/cloud (which discloses third-party data sharing) is intentionally bypassed — eliminating the headline risk by design. Assessed BLE link + physical device only. Notes B21 Pro 300 DPI variant. Recommends Approve with conditions. Version number to be assigned by Founder. |
