Secure-channel commissioning without the field pain
Provisioner Workspace is the Osprio View OSDP provisioning and commissioning tool. Set the PD address, switch baud rates, and — when the PD is in install mode — write the SCBK secure channel key directly, so secure-channel keying is no longer the painful step of an OSDP deployment.
OSDP secure channel has to start somewhere, and getting that first key onto a freshly installed PD is the part the market still hasn't made easy. Provisioning today is fragmented across vendor-specific stacks, and many of them solve one problem only by introducing another.
Some stacks move first-key delivery onto a wireless side channel — BLE, NFC, or a proprietary radio. That trades a short, wired exposure window for a new one that radiates past the panel and lives on long after the install.
Others provision cleanly only inside one vendor's reader, controller, and app combination. The key handling may be sound, but you've swapped an open protocol for a closed supply chain and the lock-in that comes with it.
Install mode is how every PD takes its first key — that part is unavoidable. The risk is running it on a populated production bus, where the unauthenticated key write is exposed to everything else on RS-485, instead of over an isolated one-to-one link to the single PD being keyed.
That is where an independent provisioner fits: reduce install-mode exposure for first trust establishment without adding an RF side channel or binding the deployment to one vendor's ecosystem.
Provisioner works two ways, and the device tells the workspace which it supports. Live quick-step mode provisions PDs one at a time, interactively: each step targets a single address, sets address and baud, keys the SCBK when the PD is in install mode, and streams the outcome straight back — ideal for benched, staged, or one-off commissioning where you want immediate feedback.
Offline mode writes a whole plan into a device slot — an independently executable work queue with one step per target PD, up to 126 per slot. On hardware that advertises autonomous execution, the device keeps working through a sealed slot while no host is connected, buffering each progress edge and streaming it back when you reconnect.
That turns offline mode into a set-it-running-and-walk-the-site workflow rather than an attended one — and the device, not the host, is the source of truth for which modes are even available.
Set each PD's bus address with a sequential, random, or manual strategy. Sequential and random work from a start address; manual takes an explicit list — so every device gets a deterministic address and the DIP-switch shuffle goes away.
Addresses are assigned as part of the plan and shown in the per-PD step review before anything is written to the device, so you confirm exactly which device lands at which address up front.
Move a PD to the baud rate the deployment actually runs at, set once per slot as the bus baud used when driving targets — no juggling separate tools or vendor utilities to change it.
The COMSET step that sets address and baud also confirms the change took effect, so a baud that did not apply surfaces as a baud_mismatch outcome rather than a silent surprise later on the production bus.
When the PD is in install mode, the step opens a controlled point-to-point session and writes the Secure Channel Base Key over it. The key reaches a single device on an isolated link — it never crosses a live, populated bus.
Keys are not typed or uploaded device by device, either. Each slot carries one 16-byte seed, generated on the host with a CSPRNG and sent to the device once at slot creation. The device derives each step's SCBK on demand from that seed, and the host runs the identical derivation locally so it always knows which key landed on which PD — while the seed itself is never written to disk, browser storage, or any export.
Setting a key is not assumed to have worked — it is proven. After KEYSET, the workspace completes a fresh secure-channel handshake using the just-set SCBK, and that handshake can only succeed if the key landed correctly. A step reports success only once the key is demonstrably working; a failure here surfaces as a secure-channel outcome instead of a false pass.
Keying also takes the PD out of install mode, so it stops accepting unauthenticated key writes. The device is handed to the production bus already locked into secure operation, not left open for anything listening on RS-485 to re-key it.
Every PD is a row showing its address and baud, a step state — pending, attempting, success, failure, or skipped — an attempt count, and a stage milestone marking which provisioning stage was last attempted, is in flight, or has stalled. success and skipped are terminal; failure is deliberately not, so retries stay unbounded and operator-driven and the device never auto-retries on its own.
When an attempt ends, the row records why: ok, no_response, wrong_address, scbk_rejected, baud_mismatch, keyset_failed, user_skipped, plus internal secure-channel errors surfaced verbatim from the device for diagnosis.
Drive each row with four verbs — try, retry, skip, reset — and the terminal outcome always arrives as a live progress edge after the verb is accepted, so the row reflects what actually happened on the bus rather than just what you requested.
Save a site's provisioning plan once and reuse it. A profile captures the device count, the address strategy with its start address or manual list, the bus baud, an optional post-programming capability check, the per-step timeout, and whether auto-verify re-reads each target after programming.
Profiles import and export as JSON, so the same plan drops onto many devices across one job without re-typing addresses, baud settings, or capability checks per PD — and auto-verify, when enabled, confirms the address, baud, and key all landed before a step is called done.
After a slot reaches complete, the derived per-PD SCBKs leave the app exactly once, in a post-completion export. It carries one entry per successfully provisioned PD — OSDP address, baud rate, and derived SCBK — for loading into downstream key-management or access-control tooling. Failed and skipped steps are omitted, and the slot seed never appears in any exported file.
Export as CSV — a flat pd_address, baudrate, scbk table for spreadsheets, scripts, and bulk import — or as JSON, a structured document with a kind tag, a file version, the slot session id, and an scbks array for programmatic ingestion. Both describe the same devices; treat either artifact as sensitive key material once it leaves the app.
Most OSDP deployments are only as secure as the moment their SCBK gets installed. Provisioner Workspace moves that moment into a controlled session against a single device, verifies the new key by re-handshaking the secure channel with it, and leaves the PD with install mode disabled — so the device joins the production bus already locked into secure operation and the rest of the protocol's guarantees actually hold in the field.
Yes. Provisioner Workspace speaks standard OSDP, so it commissions any spec-compliant PD — no vendor-specific reader, controller, or app required, and no RF side channel.
When the PD is in install mode, the SCBK is pushed over an isolated one-to-one link, verified by re-handshaking the secure channel, and install mode is disabled — so the key never crosses a live, populated bus.
Yes. Provision one PD at a time or stage a batch plan of up to 126 devices, with per-PD progress, retry, and SCBK export to CSV or JSON.
Have a question? Ask us →
Sniff a live RS-485 bus and decode every OSDP command and reply.
Stand in as a CP or PD and script tests against real readers and controllers.
Run semi-automated conformance tests and produce repeatable reports.