The access control SDK for Zephyr RTOS, from the team that builds LibOSDP. OSDP controller and reader roles, transparent reader support for PIV-class credentials, native Wiegand, NFC, and firmware update over OSDP. It is all wired into Zephyr the way Zephyr intends, so your code base stays clean and your engineers start on your product, not on the plumbing underneath it.
Unclear about your needs? Ask us a question
Many embedded SDKs bring their own world with them: a private framework, a parallel configuration system, glue code only the vendor understands. This one is a regular Zephyr module, wired in the way Zephyr's own drivers are. The product you build on it reads like a well-structured Zephyr application, because that is what it is.
OSDP buses, RS-485 transceivers, Wiegand ports and the NFC reader are all described in devicetree. Moving to a new board is a devicetree change, not a porting project.
Switch capabilities on as your product needs them. What you don't use isn't compiled in, so a simple reader stays small and a multi-door controller gets everything.
Settings, cryptography, secure storage, messaging and firmware update come from Zephyr itself, so the SDK fits in with the rest of your firmware instead of standing apart from it, and any Zephyr engineer can work on it from day one.
A reader or controller that ships is far more than an OSDP library: it has to talk to the Wiegand hardware already on the wall, read cards, keep its keys safe across power cuts, take firmware updates in the field and pass verification. The SDK brings all of it, integrated and tested together.
Controller (ACU) and peripheral (PD) on the same stack, with Secure Channel, multi-drop buses and the full command and reply set. A bus can switch roles at runtime, so one firmware can serve as a reader on one site and a controller on the next.
A Wiegand driver written for Zephyr, receiving from legacy readers and transmitting to legacy panels. Build controllers that accept OSDP and Wiegand readers side by side, readers that speak both, or converters that bridge an installed Wiegand base onto OSDP.
Integrated NFC reader support detects and identifies cards and runs smart-card exchanges, ready on the recommended development kits and portable to your own reader design.
Move files between controller and peripheral over the same OSDP link, with the transfer flow, pacing and error handling done for you. Ship configuration, display assets or credential data to devices without a second interface.
Update readers and peripherals in the field from the controller, over the bus they are already wired to. Images arrive by OSDP file transfer and go through Zephyr's native device firmware update path, so no technician has to open a housing.
Secure Channel keys and bus settings are kept across reboots, in the platform's secure key storage or a secure element. Key changes are staged and only committed once proven, so a power cut mid-rotation never strands a device off the bus.
Add manufacturer-specific commands and replies for the features that set your product apart, alongside the standard ones, without touching the protocol layer.
RS-485 transceiver control on DMA and interrupt-driven UARTs, plus OSDP over USB and other byte streams. Your board's wiring is described in devicetree, so a new board is a configuration change, not a port.
High-assurance credentials such as PIV cards need more than a card number. The controller has to hold a secure conversation with the card itself. OSDP's Transparent Reader Support makes that possible over the reader bus, and few stacks implement it end to end. This SDK implements it fully, on both sides of the link.
Your PD passes card sessions straight through to the controller. Credential logic and keys stay in the panel, and the reader stays simple, secure and cheaper to certify.
Your ACU drives card sessions through any TRS-capable reader on the bus, so it can authenticate smart-card credentials itself instead of trusting a number the reader reports.
Most failures in SIA OSDP Verified testing are not in the happy path. They are in how a device handles a key change, a baud rate change, a busy moment or a lost reply. The SDK is built by the team behind LibOSDP and the Osprio conformance tools, and it handles those cases the way the specification asks, so your device does too.
Door and multi-door controllers that drive OSDP readers, accept legacy Wiegand readers on the same panel, and keep their peripherals' firmware current over the bus.
NFC readers, keypads and I/O modules that answer as OSDP PDs, with card reading, TRS and field-updatable firmware built in.
Devices that bring an installed Wiegand base onto OSDP, or present OSDP readers to a Wiegand-only panel, during a staged migration.
Months of board bring-up, driver work and protocol scaffolding, already done — packaged as a Zephyr SDK you drop into your west workspace. The SDK overview describes what is inside in more detail.
Buildable controller, reader, Wiegand, NFC and TRS applications. Flash one, watch it work end to end, then grow it into your own firmware instead of starting from an empty main().
Our recommended setup uses popular Nordic and ST development kits that any major distributor stocks, and works out of the box. Build the whole ACU and PD system on your bench before you commit to a board design.
Not tied to our kits. Bring the SDK up on any Zephyr-supported board, whether a development kit you already own or hardware your team designed in-house, with our help if you want it.
The tests that keep the SDK correct run on emulated buses without hardware, and come with it, so you can run them in your own CI.
Integration guides, API reference and per-sample walkthroughs, plus the supported Zephyr versions and boards for every release.
Every release lists the open-source components inside it with their versions and licence texts — what your compliance review asks for, ready before it asks.
The SDK is licensed the way product companies buy components: once, for good, and without a meter running on every unit that leaves the factory.
Buy once and the licence is yours for good. Every release you have received stays licensed, so you keep building, maintaining and shipping firmware from it whether or not you renew updates.
No per-unit royalties and no seat counts. Ship ten units or ten million, with as many engineers on the SDK as the work needs.
From internal test and production tooling to a single product family or a whole business unit, the licence is scoped to the way your organisation builds products, and grows with your portfolio.
Your application and your modifications belong to you. Ship firmware to your customers, distributors and service partners while the SDK source stays with your engineering team.
The full licence terms accompany every quote, so your legal team can review them before you commit.
Access control hardware stays on the wall for a decade or more. Every licence starts with a year of updates and support, renewable year by year, built around that horizon: committed response times, a predictable release lifecycle and coordinated security handling.
Licences for shipping products come with committed response times on support requests, and reported security vulnerabilities are answered faster still. Answers come from the engineers who maintain the SDK and LibOSDP, not a generic ticket queue.
While your updates run you receive every release as it ships — patch, minor and major versions alike — including the releases that bring each new LibOSDP version into the SDK.
Releases are grouped into versioned release lines, and a line keeps receiving patch releases after newer ones appear. Take security and interoperability fixes without re-qualifying your product on a new version.
We tell you about vulnerabilities that affect your products and work with you to assess and remediate them, so a security issue in the stack is a managed event rather than a surprise in the field.
Security fixes to LibOSDP are published upstream under Apache-2.0 for everyone. The open-source core underneath your product never waits on a contract.
If you stop renewing, nothing is taken away. Every release you received stays licensed, your current release line keeps its patch releases until it is retired, and you can come back to the latest release whenever you choose.
The SDK is Zephyr-native rather than a library bolted onto Zephyr: it is configured through devicetree, built with west and structured the way Zephyr applications already are. When your product needs more than the samples show, the team that wrote it helps you get there.
Help getting the SDK running on your hardware: the devicetree, the RS-485 transceiver and its direction control, Wiegand lines, the NFC front end, a secure element, and the bus timing your readers and controllers expect.
Hands-on work on the application around the SDK — your device behaviour, manufacturer-specific commands, card formats and product-level requirements — as much or as little as you need.
Run Conformance Workspace on Osprio Mini against your device and fix the gaps on your own bench, before you send it for SIA OSDP Verified testing.
No. OSDP is the core, but the SDK covers what an access control device needs around it: a native Zephyr Wiegand driver for receiving from and transmitting to legacy hardware, NFC card reading, Transparent Reader Support for PIV-class credentials in both roles, file transfer and firmware update over OSDP, secure key storage and secure element integration, and manufacturer-specific commands. All of it is wired in through devicetree, Kconfig and Zephyr's own subsystems, so your code base stays a clean Zephyr application. The SDK overview walks through each area.
Yes. The SDK fully implements OSDP Transparent Reader Support (TRS) in both roles. A reader built on it passes card sessions through to the controller, and a controller built on it drives card sessions through any TRS-capable reader. That lets the panel authenticate PIV-class credentials itself, over Secure Channel, instead of trusting a card number reported by the reader.
Yes. The Wiegand driver runs alongside OSDP on the same device, in either direction. A controller can take OSDP and Wiegand readers on the same panel, a reader can offer both outputs, and a converter can bridge an installed Wiegand base onto OSDP during a staged migration. Card formats stay in your application, and the SDK provides the helpers to build and parse them.
Yes. Firmware images travel from the controller to the peripheral by OSDP file transfer and are applied through Zephyr's native device firmware update path, so devices in the field are updated over the bus they are already wired to. The same file transfer support is available for your own files, such as configuration or display assets.
SIA runs OSDP Verified testing on your finished product, so no SDK can certify it for you. What the SDK does is handle the cases where devices most often fail — key changes, communication setting changes, busy and error replies, Secure Channel behaviour — the way the specification asks. Pair it with Conformance Workspace to test your device on your own bench before you submit it.
Our recommended evaluation setup uses popular Nordic and ST development kits, stocked by every major electronics distributor, and works out of the box. You can build and test a complete ACU and PD system on it before committing to a board design. You are free to bring the SDK up on any other Zephyr-supported board, including one you designed in-house: your OSDP bus, Wiegand ports and NFC reader are described in devicetree, so a new board is a devicetree change, not a port. Each release documents the Zephyr versions and boards it supports, and hands-on bring-up help is available.
Yes. The licence is perpetual and royalty-free — no per-unit fees and no seat counts, at any production volume. It starts with a year of updates and support that renews year by year. If you stop renewing, you keep every release you received and can go on building, maintaining and shipping products with it.
Licences are scoped to how your organisation builds — from internal test and production tooling, through a single product family, to a whole business unit — and can grow as your portfolio does. Tell us what you are building and we will quote the licence that fits; the full licence terms come with every quote.
Licences for shipping products include committed response times, with reported security vulnerabilities handled first. While your updates run you receive every release as it ships, we notify you of vulnerabilities relevant to your products and work with you on remediation. Releases are grouped into maintained release lines, so security and interoperability fixes arrive as patch releases without forcing a move to a new version. Security fixes to LibOSDP itself are published upstream for everyone.
LibOSDP is our open-source OSDP library and stays under the Apache License 2.0. The OSDP Zephyr SDK is the commercial layer on top: the Zephyr integration, the Wiegand, NFC and firmware update support, sample applications, documentation, and the maintained releases and support that come with them. Your rights to LibOSDP under its own licence are never limited by the SDK licence.
Osprio Pro firmware is built on this SDK. We depend on it ourselves, so it stays maintained and you get support from the people who ship on it.
Have a question? Ask us →