Connected products that ship without a shared password.
The product team wants the companion app done. Compliance wants to talk about the Cyber Resilience Act. We work on the layer in between, device identity, secure updates, vulnerability handling and the cloud backend, so the product can be sold where you plan to sell it.
Companion appiOS · AndroidMatter controllersApple Home · Google Home · Alexa
Auth0HashiCorp VaultTerraformMicrosoft Entra ID
in short·20-second read
Smart devices are consumer and commercial products that connect to an app or cloud service, such as cameras, thermostats, locks and appliances.
Cohash builds the backend and the security plumbing for them. That means per-device credentials, signed over-the-air updates, a vulnerability reporting process, and readiness for ETSI EN 303 645, the UK PSTI regime and the EU Cyber Resilience Act, which applies in full from 11 December 2027.
you probably need this if
Units leave the factory with the same default password printed on the label.
Firmware updates are unsigned, or signed with a key that sits on a build server.
There's no published way for a researcher to report a vulnerability in your product.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Smart Devices, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · smart devices3 open
openUnits leave the factory with the same default password printed on the label.
recurringFirmware updates are unsigned, or signed with a key that sits on a build server.
blockedThere's no published way for a researcher to report a vulnerability in your product.
exposure
Per-device identitySigned over-the-air updatesVulnerability handling and CRA…Companion app and cloud backendMatter and ecosystem integration
startrehearsehandover
Product and market review
Gap assessment
Build the fixes
Evidence and handover
we are here
ready to hand over
The reports go in on time and say what they have to.
Owning the build server isn't enough to sign firmware any more.
Applicability map of regulations per product and market
Gap assessment against ETSI EN 303 645 and CRA essential requirements
chapter 01 · where it hurts
Why teams reach out
Units leave the factory with the same default password printed on the label.
Firmware updates are unsigned, or signed with a key that sits on a build server.
There's no published way for a researcher to report a vulnerability in your product.
chapter 02 · what we change
How we solve it
Per-device identity
Signed over-the-air updates
Vulnerability handling and CRA reporting
Companion app and cloud backend
Matter and ecosystem integration
chapter 03 · how it runs
Our approach
Product and market review
Gap assessment
Build the fixes
Evidence and handover
chapter 04 · where you end up
What changes
The reports go in on time and say what they have to.
Owning the build server isn't enough to sign firmware any more.
Applicability map of regulations per product and market
Gap assessment against ETSI EN 303 645 and CRA essential requirements
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
Unique credentials injected at manufacture or generated on first boot, with the private key kept in a secure element when the hardware has one. No universal default passwords, which UK law has required since 29 April 2024.
Firmware signing, staged rollout, rollback and a published support period. An update you can't push is a vulnerability you can't fix.
A disclosure contact, triage process and the reporting workflow the CRA has required since 11 September 2026, with early warnings for actively exploited vulnerabilities due within 24 hours.
We build account linking, device claiming and household sharing on CIAM, so a resold device doesn't stay tied to whoever owned it before.
Backends and commissioning for Matter, Apple Home, Google Home and Alexa. If the hardware can do it, we add Matter 1.6 features such as NFC commissioning and Joint Fabric.
capability 01 / 05in production
Per-device identity
Unique credentials injected at manufacture or generated on first boot, with the private key kept in a secure element when the hardware has one. No universal default passwords, which UK law has required since 29 April 2024.
A disclosure contact, triage process and the reporting workflow the CRA has required since 11 September 2026, with early warnings for actively exploited vulnerabilities due within 24 hours.
Backends and commissioning for Matter, Apple Home, Google Home and Alexa. If the hardware can do it, we add Matter 1.6 features such as NFC commissioning and Joint Fabric.
We pieced these together from Smart Devices situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Exploited flaw in an older camera on the EU market
composite · not a client story
Beforethe situation
A researcher reports active exploitation of a known flaw in an older camera model that has been sold in the EU for years. Since 11 September 2026 the CRA requires a report through ENISA's Single Reporting Platform.
What we dothe work
Confirm the exploitation with the product team and work out which firmware versions are hit. File the early warning inside 24 hours and the notification inside 72. Draft user guidance while the fix is built and staged through signed OTA. Then the final report, within 14 days of the fix.
Afterwhere you end up
The reports go in on time and say what they have to. The fix uses the usual update pipeline. And the runbook isn't theoretical any more.
case file 02
Thermostat firmware signed with a key on the build server
composite · not a client story
Beforethe situation
A thermostat maker signs its OTA images with a private key that lives on the CI build server. Every update goes to every device at once. If an image bricks one hardware variant, there's no way back.
What we dothe work
The signing key moves into an HSM or cloud KMS, behind its own approved signing step. Devices check signatures and refuse older images, which blocks rollback attacks. Rollouts go in stages with health checks, and A/B partitions let a failed device boot the previous image.
Afterwhere you end up
Owning the build server isn't enough to sign firmware any more. A bad image stops at the first stage.
Where identity and updates fit around a connected product
Each device gets a unique credential at the factory and only accepts firmware signed by your release key. Owners claim the device through a CIAM-backed app, and the device can also join Matter ecosystems.
We don't start a step until the last one has produced something you can check.
step 01
Product and market review
Device models, markets you sell into, and which regimes apply to each. The CRA, PSTI and radio rules don't line up neatly.
step 02
Gap assessment
Each requirement gets checked against today's device, app and backend. Missing evidence and missing engineering go on separate lists.
step 03
Build the fixes
Build the identity, update and reporting changes into the firmware pipeline and backend. Test them on production hardware.
step 04
Evidence and handover
Technical documentation, support-period statements and runbooks your product security team can maintain.
you keep
What you're left with
We write these for your Smart Devices setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Applicability map of regulations per product and market
yours to keep
report02
Gap assessment against ETSI EN 303 645 and CRA essential requirements
yours to keep
design03
Device identity and update architecture
yours to keep
runbook04
Vulnerability handling and CRA reporting runbook
yours to keep
report05
Technical documentation pack for conformity assessment
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Embedded firmware engineer
Mobile app developer
Device identity engineer
Cloud back-end developer
Connected device QA engineer
due diligence · smart devices
Questions to ask any partner, including us.
Put these to anyone bidding on your Smart Devices work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which of our products and markets fall under the CRA, PSTI or both?
Obligations depend on product category and where it's sold. Do the applicability map first, because it decides how much of everything else you actually have to do.
Q2
Who on our side can file a CRA early warning within 24 hours, weekends included?
The clock starts when you become aware. A named on-call owner and a drafted template matter more than the policy document.
Q3
Where is our firmware signing key, and who can use it?
Ask where the signing key lives. If it's on a build server or a developer laptop, it can sign malware your devices will trust.
Q4
How will you set and publish a support period for each product?
PSTI requires a stated minimum support period, and the CRA expects one too. The number has to match what engineering can actually patch.
Q5
How do devices get unique credentials on the production line?
PSTI bans universal default passwords. Per-device credentials need a step in manufacturing, and a contract manufacturer who actually follows it.
01Does the Cyber Resilience Act apply to products we already sell?
The reporting duties do. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents for products on the EU market, including ones placed there before the main rules start. Most other obligations, such as essential requirements and CE marking, apply from 11 December 2027.
02Is meeting ETSI EN 303 645 enough for the UK?
UK PSTI is built on ETSI EN 303 645 and the UK Code of Practice. Its three legal requirements cover passwords, a way to report security issues and a stated minimum support period. Meet the full standard and you cover those and more. You still need a statement of compliance for each product.
03Should we support Matter?
If you sell smart home products into more than one ecosystem, usually yes. One certified device can work with several controllers. It does add certification cost and a commissioning flow you have to support, so we look at your hardware, chipset and roadmap before recommending it.
04How long does CRA readiness take?
It depends on how many product lines you have and whether your update pipeline is already signed and staged. Teams with a working OTA system mostly need process and documentation. Teams without one have firmware work ahead of them, and that takes the longest.
05What are the CRA reporting deadlines?
For an actively exploited vulnerability or a severe incident, an early warning is due within 24 hours and a notification within 72 hours. The final report is due within 14 days of a fix for vulnerabilities, or within a month of the notification for incidents. Reports go through ENISA's Single Reporting Platform.
related
Often paired with
Projects on Smart Devices usually end up touching one of these, so they're worth a look.
