Platforms
- Nordic nRF series SoC
- STM32 microcontrollers
How we work
Engineering Approach
Standards for firmware, workflow from requirements to delivery, and how we integrate with your stack.
Technical Requirements
We follow a consistent engineering standard to ensure scalability, maintainability, and production-grade security.
RTOS & Architecture
- Zephyr / FreeRTOS
- RTOS-based, modular design
- Concurrency and isolation for secure components
Bare-metal projects are generally not a good fit. We recommend introducing an RTOS to enable proper system structure and security mechanisms.
Languages
- C++ (primary)
- C (when required by platform constraints)
These requirements ensure that security mechanisms can be properly implemented, audited, and maintained in production systems.
Project Workflow
Expert engineering & security integration
1. Requirements Definition
We define the project goals and constraints - a clear description of the expected outcome. At this stage we refine requirements together and identify key technical decisions.
2. Threat Modeling
We analyze realistic attack vectors such as firmware extraction, device cloning, debug access, and backend impersonation. This defines the security scope and priorities of the system.
3. Security Architecture Definition
Based on the threat model, we design the device security architecture - including identity, provisioning, authentication, firmware updates, and communication.
4. System Specification
We produce a detailed specification describing system behavior, interfaces, protocols, and security mechanisms. This document becomes the implementation baseline.
5. Specification Review
The specification is reviewed with the client and refined as needed. It serves as the agreed foundation for development.
6. Project Estimation
We estimate timeline and budget based on the approved specification. Development begins after alignment.
7. Development Phase
Implementation is carried out according to the specification, with continuous internal testing. Deliverables may include firmware, tools, and supporting services.
8. Client Testing
The client validates the solution in the real product environment. Final adjustments and integration fixes are completed at this stage.
9. Project Completion
After all issues are resolved, the project is finalized and delivered, including updated documentation reflecting the final implementation.
Backend Integration
A secure device lifecycle requires supporting backend systems for manufacturing, provisioning, firmware signing, and updates.
We can integrate our firmware and security architecture with your existing backend, adapting protocols and flows to your infrastructure.
Alternatively, we can provide our own backend platform, delivered with source code and tailored to your project requirements.
Our platform is implemented in .NET and designed for deployment on Microsoft Azure, supporting device provisioning, firmware signing, identity management, and lifecycle operations.
Companion Applications & Protocols
Connected devices typically require companion applications for configuration, testing, and daily operation.
We design communication protocols between devices and applications (BLE, USB, or custom transports) with security and reliability in mind.
We can also deliver reference mobile or desktop applications that implement these protocols and demonstrate full device interaction.
We also provide dedicated debugging and testing tools that allow engineers to inspect device behavior, validate communication flows, and troubleshoot issues during development and production.
These applications and tools can be used as a foundation for your own product development, reducing time to market and ensuring correct protocol implementation.
Frequently Asked Questions
Practical questions about how our engineering process works.
Does the timeline and budget get estimated before or after the technical specification?
After. Estimation happens once the System Specification is reviewed and approved - Project Estimation is step 6 of our workflow, following Requirements Definition, Threat Modeling, Security Architecture, Specification, and Specification Review. We estimate against an agreed specification, not a rough idea.
Do you only design security, or build the full firmware?
Depends on scope, defined at the Requirements Definition stage. Development deliverables can include full firmware, targeted security components integrated into your existing codebase, or both, along with supporting tools and services.
Can you add security to a device we've already built, or only design it in from scratch?
Both. Adding security to an existing embedded system is one of the most common reasons clients engage us - not just greenfield designs.
What's the most common mistake you see in existing embedded security implementations?
Almost always an early architectural decision, not an implementation bug: no strong device identity from the start, weak or missing provisioning during manufacturing, secrets stored in firmware or reachable via debug interfaces, or no secure update mechanism. These are cheap to get right early and expensive to fix once a fleet is already deployed.
Do you work under NDA?
Most of our projects are delivered under NDA. Confidentiality terms are part of scoping a project, typically agreed before the Requirements Definition stage begins.
Summary
We approach every project as a complete embedded and IoT device ecosystem - combining firmware, security architecture, backend integration, and companion applications into a cohesive system.
This ensures that devices are not only functional, but secure, verifiable, and maintainable throughout their entire lifecycle.
Such an approach also helps align device architectures with modern regulatory expectations, including frameworks such as the Cyber Resilience Act (CRA).
See how this approach translates into a project on the Services page.