How a Smart Lock Is Made: Motors, Secure Elements, Firmware, Matter

A smart lock is a mechanical deadbolt driven by a small geared DC motor, controlled by a low power wireless microcontroller that speaks Bluetooth LE plus Thread or Wi-Fi, with a secure element or protected key store holding the keys that decide who may open the door. It pairs through Matter's onboarding code and updates with signed firmware images.

The mechanical half is graded under ANSI/BHMA residential standards, the electronic half is authorised for radio use by the FCC and certified for interoperability by the Connectivity Standards Alliance (CSA), and since February 2026 phone keys have their own standard, Aliro 1.0. This guide walks the build from gearbox to the factory line where firmware is flashed and device keys are provisioned, then through commissioning, updates, attack categories and the rules in the US, UK and EU. It extends our explainers on Zigbee, Thread and Matter and Bluetooth LE pairing and bonding one level down into a single device. Every date, field size and rule below was checked against the primary sources listed at the end; where a source left a question open, we say so.

Key takeaways

• A smart lock has two halves that fail differently. The mechanical half is rated under ANSI/BHMA standards (for homes, A156.39 for locksets and latches and A156.40 for deadbolts); the electronic half is a battery powered radio computer with a motor, bolt sensors, a wireless SoC, often NFC or Ultra-Wideband (UWB), a secure element and a mechanical override.
• Matter commissioning starts from a QR code beginning MT: or an 11 digit manual code carrying a 27 bit setup passcode and a 12 bit discriminator. The lock proves it is genuine with a factory installed Device Attestation Certificate, then receives an operational certificate and network credentials.
• Aliro 1.0, published by the CSA on 26 February 2026, standardises phone and wearable keys over NFC, Bluetooth LE, and Bluetooth LE plus UWB, using asymmetric cryptography, with a certification programme run through authorised test labs.
• Firmware is usually a real time operating system with Matter, Thread or Wi-Fi and crypto stacks, booted by a bootloader that checks every image's signature and can refuse downgrades. The update path decides how long the lock stays safe.
• ETSI EN 303 645 and the UK PSTI regime require no universal default passwords, a published way to report vulnerabilities and a published support period. The EU Cyber Resilience Act's reporting duties apply from 11 September 2026 and its main obligations from 11 December 2027. The FCC's US Cyber Trust Mark is voluntary and, as of October 2026, still being stood up.
• Realistic attacks fall into a few families (relayed proximity unlock, replayed radio messages, leaked shared codes, account compromise, physical force), and each has a known engineering answer.

What is inside a smart lock?

Open any retrofit or full replacement smart lock and you find the same building blocks, arranged around one constraint: it has to run for months on batteries while listening for a phone, a hub and a finger on the keypad.

Motor, gearbox and the force budget

The motor is a small brushed DC motor driving a multi stage reduction gearbox of plastic and metal gears, which trades speed for the torque needed to push a bolt that rubs on a misaligned strike. Firmware watches motor current: a sharp rise means the bolt has hit its end stop or jammed. Good designs stop at the first stall, back off so the gear train is not left loaded, and report a jam instead of retrying until the batteries are flat.

A retrofit lock sits on the inside of the door and turns the existing thumbturn, so the exterior cylinder and deadbolt are whatever the house already had. A full replacement lock brings its own deadbolt, exterior escutcheon and often a keypad. That difference matters for ratings: a retrofit lock inherits the grade of the deadbolt it turns, while a full replacement lock carries its own BHMA rating, if the maker has had one tested.

Bolt position and door state sensing

The lock needs to know where the bolt is and whether the door is closed. Bolt position usually comes from a magnet on the cam read by a Hall effect sensor; door state from a separate magnet on the frame. Without the second sensor, a lock can report "locked" while the bolt sticks out of an open door, and auto lock depends on both.

The microcontroller and radios

Most current locks use a single wireless SoC that combines an Arm Cortex M class core, flash, RAM, a Bluetooth LE radio and an IEEE 802.15.4 radio for Thread. Wi-Fi locks either use a Wi-Fi SoC directly or pair a low power radio in the lock with a separate Wi-Fi bridge plugged into a wall outlet, because Wi-Fi draws far more current than a battery powered lock can afford if it listens continuously. Thread suits locks well: it is a low power mesh where the lock can be a "sleepy end device" that wakes on a schedule, and it carries IPv6, which is what Matter runs over.

Bluetooth LE does two jobs: it is the channel Matter uses to commission a new device, and the channel the maker's own app uses for nearby control. The Bluetooth SIG's core specification page lists Core Specification 6.3 as the current adopted version; a lock implements only the features it needs.

NFC adds tap to unlock. Aliro and the existing phone wallet home keys both use NFC for the tap case. UWB, where present, is a separate radio used for precise ranging, so the lock can tell whether a phone is actually at the door rather than somewhere in the house.

The secure element

A secure element is a small tamper resistant chip, or a protected enclave inside the SoC, that stores keys and performs cryptographic operations without ever releasing the private key to the main processor. In a lock it typically holds the device's identity private key (for Matter, the private key behind its Device Attestation Certificate), the keys that verify phone credentials, and sometimes the material used to check PINs. Some lock designs use a discrete secure element on the I2C or SPI bus; others rely on the SoC's built in key storage and hardware crypto. Both approaches can meet ETSI EN 303 645 provision 5.4-1, which requires sensitive security parameters in persistent storage to be "stored securely".

Keypad and fingerprint sensors

Keypads are either capacitive touch panels or physical buttons. A capacitive panel avoids worn keys that reveal the code, and many locks add a "scramble" feature that lets you type random digits around the real code. Fingerprint sensors are capacitive arrays with their own matching processor; the fingerprint template should stay on the sensor module or in protected storage and never leave the lock.

Batteries and the mechanical override

Most locks run on four AA cells, a few on rechargeable packs. Firmware should estimate charge from voltage under motor load, because a cell that reads fine at rest can sag under a stall. A lock with no power must still open from outside by an approved route: a key cylinder or an external emergency power contact.

How is the mechanical side designed and rated?

The mechanical side is rated by the Builders Hardware Manufacturers Association (BHMA), which develops the ANSI/BHMA A156 series of American National Standards for door hardware. BHMA describes its product grades as grade 1, 2 or 3, "with grade 1 being the highest", defined by progressive performance benchmarks in each applicable ANSI/BHMA standard. BHMA's certified products directory lists products tested against performance standards "having cycle, operational, strength, security, and finish test requirements".

For homes, BHMA runs a separate residential scheme, promoted through its Secure Home website, under two standards: A156.39 for residential locksets and latches and A156.40 for residential deadbolts. Instead of a single grade, residential products carry a ratings combination across security, durability and finish, so a buyer can see, for example, a top security rating with a middle durability rating. Certification is voluntary and done by independent laboratory testing, and BHMA notes that a maker does not have to be a BHMA member to certify a product.

What the tests actually do, in categories: cycle tests run the lock through many lock and unlock operations to prove the mechanism and finish survive; strength and security tests apply impact, torque and pull loads to the bolt, cylinder and housing; finish tests expose the surface to corrosion and wear. The full test procedures and numerical thresholds are in the purchased standards, not on BHMA's public pages, so check the standard itself before quoting a cycle count.

Two practical lessons follow. First, an electronic lock's rating only covers the hardware that was tested, so a retrofit device that turns your existing thumbturn adds no mechanical strength. Second, the strike plate and frame screws often decide the outcome of a forced entry, and no smart feature fixes a short screw in soft wood.

How are keys and credentials stored?

A smart lock juggles several kinds of credential, and each wants different storage.

The Matter Door Lock cluster, as implemented in the open source Matter SDK, models users and credentials explicitly. Its credential types are a programming PIN, PIN, RFID, fingerprint, finger vein and face, plus three Aliro key types (a credential issuer key and evictable and non evictable endpoint keys) added for phone credentials, and each credential belongs to a user whose type sets when it works: unrestricted, week day or year day schedule, expiring, disposable (one time use), remote only, and a few others. That model is why a Matter controller can create a guest code that only works on weekdays from 9 to 5 without touching the maker's cloud.

What a secure element protects against, and what it does not

A secure element is built to resist extraction of keys by someone who has the device in their hands: probing the chip, glitching its power or clock, reading flash, or analysing its power use while it signs. It protects the device identity key so a lock cannot be cloned into a fake that passes Matter attestation, and it keeps reader keys from leaking out of a lock that was stolen or bought second hand.

It does not protect against logic bugs in the firmware that decides when to ask the secure element to do something. If the firmware unlocks when a malformed Bluetooth message arrives, the secure element never gets a vote. It also does nothing for credentials that are weak by design, such as a four digit PIN with no attempt limit, or a card scheme that sends a fixed identifier. ETSI EN 303 645 provision 5.4-2 captures the narrower point a secure element addresses: where a hard coded unique per device identity is used for security, it "shall be implemented in such a way that it resists tampering by means such as physical, electrical or software."

GlobalPlatform publishes the secure element and trusted execution environment specifications many of these chips implement, plus the SESIP evaluation standard for IoT platforms; a chip's datasheet says which it follows.

How does commissioning work?

Commissioning is the process of turning a lock fresh out of the box into a trusted member of your home network. With Matter it has a defined sequence.

Step 1: read the onboarding payload

The lock ships with a QR code and an 11 digit manual pairing code, on the device, in the box or both. In the Matter SDK, the QR code text starts with the prefix MT: and encodes a 3 bit version, the 16 bit vendor ID and 16 bit product ID, a commissioning flow field, an 8 bit field saying which discovery methods the device supports, a 12 bit discriminator and a 27 bit setup passcode. The discovery bits cover Wi-Fi soft AP, Bluetooth LE, on network discovery, Wi-Fi Public Action Frames and NFC based commissioning. The manual code carries only 4 bits of the discriminator, which is why it is shorter than the QR payload.

The setup passcode is the secret: anyone holding it and in radio range while the lock is in commissioning mode can try to commission it, so commissioning windows time out and the QR code should never be posted.

Step 2: find the lock and set up a session with the passcode

The controller (a phone app or a hub) finds the lock over Bluetooth LE using the discriminator, then runs PASE, the passcode authenticated session establishment, which turns the shared setup passcode into an encrypted session without sending the passcode itself.

Step 3: device attestation

Inside that session, the controller asks the lock to prove it is a genuine certified product. The controller extracts the lock's Device Attestation Certificate (DAC) and its Product Attestation Intermediate (PAI) certificate, which carry the vendor ID, product ID and attestation public key, and sends a challenge that the lock must sign with its attestation private key, held in protected storage. The PAI in turn chains to a Product Attestation Authority (PAA), and the CSA publishes the PAAs it trusts alongside its Distributed Compliance Ledger, a signed and publicly auditable ledger run by Alliance members. A counterfeit lock without a valid chain and private key fails here.

Step 4: operational credentials and network join

The controller then sends a certificate signing request. The lock generates a fresh operational key pair, returns the request, and the controller's administrative domain issues a Node Operational Certificate (NOC) for its fabric (your home's Matter network for that ecosystem). The controller installs the fabric's root certificate and the NOC, plus access control entries. For a Thread lock, it hands over the Thread operational dataset, which contains the network key and other parameters, so the lock can join the mesh via a Thread border router. For a Wi-Fi lock, it hands over the Wi-Fi network name and password. From then on, the lock and controllers talk over CASE, the certificate authenticated session, not over the setup passcode.

Step 5: multi admin

Matter allows several fabrics on one device, so a lock can be controlled by more than one ecosystem at once. Each additional ecosystem is added by opening a new commissioning window from an existing admin, which generates a fresh temporary passcode. This is also the escape hatch when one ecosystem shuts down: the lock keeps working locally with the others.

BLE provisioning without Matter

Many locks still ship with a maker's own Bluetooth LE provisioning flow alongside Matter or instead of it. That flow typically pairs the lock to a cloud account, then lets the phone app act as a key. Its security depends entirely on the maker's design, so ask whether it uses authenticated encryption with fresh challenges and whether the lock can be controlled locally if the cloud is gone.

What is Aliro?

Aliro is the CSA's standard for using phones and wearables as access credentials, the "digital key" half of the problem that Matter does not cover. The CSA announced the Aliro 1.0 specification on 26 February 2026. According to the announcement, it supports NFC for tap to access, Bluetooth LE for user initiated longer range communication, and Bluetooth LE plus UWB for hands free authentication, uses asymmetric cryptography between user devices and readers, and comes with a certification programme and test suites run through authorised test labs. The CSA says more than 220 member companies took part and that Apple, Google and Samsung wallets are aligned with it.

By late 2026, CSA's certified products database lists locks and lock development platforms that combine Matter over Thread with Aliro over NFC and UWB.

Timeline: the standards and rules behind a smart lock

How is a smart lock manufactured and tested?

A smart lock is two products assembled into one: a mechanical lock built on metal working lines and an electronic module built on a surface mount technology (SMT) line, joined in final assembly and tested as a whole.

The electronics

The printed circuit board starts as bare laminate with copper layers. On the SMT line, a stencil prints solder paste onto the pads, pick and place machines set the SoC, secure element, motor driver, regulators, antenna matching parts and sensors, and a reflow oven melts the paste. Automated optical inspection checks placement and joints; X-ray checks hidden joints under packages like the SoC. In circuit or flying probe tests check for opens and shorts.

Then comes functional test, where security begins: a fixture powers the board, flashes the bootloader and application, writes per device data and runs self tests. Per device data includes the serial number, the Matter DAC and its private key (either injected from a hardware security module on the line or generated inside the secure element so the private key never leaves it), the onboarding passcode and discriminator, and the hash of the firmware signing key into one time programmable memory. Debug ports are then locked; ETSI EN 303 645 provision 5.6-4A requires debug interfaces to be "disabled or protected via a best practice authentication or access control mechanism".

RF calibration follows: the fixture measures each radio's frequency offset and output power and writes trim values, then checks that Bluetooth LE, Thread and NFC links work at expected signal levels.

The mechanics

The lock body, bolt, strike and housing are made by die casting, stamping and machining, then finished by plating or coating. The gearbox is assembled from moulded and metal gears and joined to the motor. Each motor and gearbox unit is run on a torque test rig to confirm output torque and stall current are in range.

Final assembly and product tests

Every assembled unit is run through lock and unlock cycles to check bolt sensing; sample units go through extended cycle, battery life, temperature, humidity and drop tests. The QR code and label are printed from the same database that holds the onboarding passcode, which is why label printing is part of the security process.

Regulatory testing

In the US, a lock with a radio transmitter is a radio frequency device that needs FCC equipment authorisation before it can be marketed. The FCC's equipment authorisation page explains that devices which need certification are tested by an accredited lab and approved by a Telecommunication Certification Body, and the grant is published under an FCC ID you can look up. Interoperability certification for Matter and Aliro is separate, run through the CSA's authorised test labs.

Step table: raw materials and silicon to boxed lock

Steps 4 and 5 are the two places a lock's whole security posture gets fixed into hardware. A wrong signing key hash or a debug port left open there cannot be repaired by a later update.

What firmware runs on a smart lock?

A typical battery lock runs a real time operating system rather than Linux, because the SoC has hundreds of kilobytes of RAM, not hundreds of megabytes. The stack usually looks like this:

How signed updates work

MCUboot is a good example of how a secure update path is built, because its design is public. Each firmware image carries a header and a set of trailing records, including a hash of the image and a signature over it; the documentation lists supported signature types including RSA 2048 and 3072 with PSS, ECDSA and Ed25519. The bootloader holds the public key, or a hash of it, and refuses to boot an image whose signature does not verify.

An update is downloaded into a secondary slot. On the next reset the bootloader verifies it and either swaps it into the primary slot or overwrites the primary slot, a choice fixed at build time. A "test" swap lets the device roll back to the old image if the new one crashes before confirming itself, which keeps a bad build from bricking a lock on a door. For downgrade protection, MCUboot can compare version numbers in software, or compare a hardware backed security counter carried in the image, so an attacker cannot reinstall an older, vulnerable but validly signed version.

Matter adds a standard delivery path on top: the lock implements the OTA Requestor cluster and asks an OTA Provider (a hub, bridge or app on the same fabric) for a newer image, which it downloads into the secondary slot. The Matter SDK ships a reference OTA Requestor app that shows the flow end to end. Wi-Fi locks built on other SoCs use equivalent mechanisms; the ESP-IDF documentation for the original ESP32, for example, describes Secure Boot v2 verifying RSA-PSS signatures on the second stage bootloader and the application, with the SHA-256 digest of the public key written to a write protected eFuse block.

ETSI EN 303 645 sets the expectations in plain terms. Provision 5.3-2 requires a secure update mechanism, 5.3-7 requires "best practice cryptography" for it, 5.3-8 says security updates shall be timely, and 5.3-10 requires a device receiving updates over a network interface to verify their authenticity and integrity.

What happens when the maker ends support or the cloud closes?

Three different things can end, and they fail differently.

• Security updates end. The lock keeps working but no longer gets fixes for its Bluetooth, Thread, Matter or crypto code. ETSI EN 303 645 provision 5.3-13 requires the maker to publish the defined support period, and the UK PSTI regime requires a published minimum security update period with an end date.
• The cloud service closes. Any feature that ran through the maker's servers stops: remote unlock through the maker's app, cloud stored audit logs, guest code creation through the app. A lock that also speaks Matter keeps local control through the other controllers on its fabrics.
• The app is withdrawn from app stores. Bluetooth only locks that depended on the maker's app for every operation can be left with only their keypad and key.

Buyers should choose locks that keep working locally through a standard (Matter for control, Aliro or a keypad for entry) and note the published support end date. For makers selling in the EU, the Cyber Resilience Act turns the same idea into law: the European Commission's summary says manufacturers must handle vulnerabilities during the lifecycle of their products, not just at launch.

Step by step: build, sign, commission and inventory a lock firmware

This walkthrough is for a firmware team working on its own development hardware, using open source tooling that is common in Matter over Thread lock projects. It shows the signing, commissioning and inventory steps; it does not and should not show anything about opening a lock you do not own.

1. Generate a signing key and keep it off the build server

# Generate an ECDSA P-256 signing key with MCUboot's imgtool
pip install imgtool
imgtool keygen -k lock-signing-ec-p256.pem -t ecdsa-p256

# Export the public key as C source for the bootloader build
imgtool getpub -k lock-signing-ec-p256.pem > signing_pub_key.c

In production the private key belongs in a hardware security module or a signing service with approvals, never on a laptop or in the repository. Keep the test key and the production key separate, and make sure the production bootloader only trusts the production key.

2. Build and sign the application image

# Zephyr based build of a Matter lock sample (board name is an example)
west build -b <your_board> path/to/lock-app

# Sign with a version and a security counter for downgrade protection
imgtool sign \
  --key lock-signing-ec-p256.pem \
  --header-size 0x200 --align 4 \
  --version 1.4.0 --security-counter 7 \
  --slot-size 0x60000 --pad-header \
  build/zephyr/zephyr.bin lock-app-1.4.0-signed.bin

# Verify the signature before release
imgtool verify -k lock-signing-ec-p256.pem lock-app-1.4.0-signed.bin

The header size, alignment and slot size must match your flash layout; copy them from your partition configuration rather than from this example.

3. Flash a development board, after checking which probe is attached

Warning: flashing with a full chip erase destroys everything on the target, including any factory provisioned attestation keys and onboarding data on that board. Never run it against a production unit.

# First, list the attached debug probes and confirm the serial number
pyocd list

# Only after confirming the probe serial belongs to your dev board.
# Check your runner's probe selection option with: west flash -H
west flash --erase <runner-probe-option> <probe-serial-from-the-list-above>

4. Commission the lock in a lab and test credentials

The Matter SDK's chip-tool is the reference command line controller. On a lab network with a Thread border router, commissioning over Bluetooth LE looks like this:

# Get the active Thread dataset from your border router (OpenThread CLI)
ot-ctl dataset active -x

# Commission node 1 over BLE into Thread using the manual pairing code
chip-tool pairing code-thread 1 hex:<dataset-hex> <11-digit-manual-code>

# Read the lock state, then lock with a timed interaction
chip-tool doorlock read lock-state 1 1
chip-tool doorlock lock-door 1 1 --timedInteractionTimeoutMs 1000

Lock and unlock commands in the Door Lock cluster require a timed interaction, which stops a captured command from being replayed later; your tests should confirm that the device rejects them without one.

5. Produce an SBOM for the firmware build

# Zephyr can emit SPDX documents for a build.
# First enable CONFIG_BUILD_OUTPUT_META=y in the application's prj.conf,
# then build and generate (SPDX 2.3 tag-value by default)
west build -b <your_board> path/to/lock-app -d build
west spdx -d build
ls build/spdx/   # app.spdx, zephyr.spdx, build.spdx, modules-deps.spdx

Zephyr writes separate documents for the application sources, the Zephyr sources used, the built output files and module dependencies. Together they list the Zephyr modules, the Matter SDK, OpenThread, the crypto library and your application. With sysbuild, point west spdx at the application's own build directory. That inventory is what you check when an advisory names a Bluetooth host stack, a Thread component or a TLS library.

6. Scan the companion app and the inventory

# Scan the companion app repository and the firmware SBOM with the Safeguard CLI
safeguard scan --dir ./lock-companion-app
safeguard scan --sbom build/spdx/app.spdx

Results land as JSON under ./output. This step covers the software you build and ship; it says nothing about the radio firmware blobs or boot ROM supplied by a chip vendor.

What are the realistic attacks on a smart lock?

These are categories with their engineering answers, described conceptually. None of them needs a movie style hack, and most of them are about design choices made long before the lock reached a door.

Relay attacks on proximity unlock

Hands free unlock decides the phone is "near" from a radio link. If the lock only checks Bluetooth LE signal strength or that a connection exists, relaying equipment can make a distant phone appear close. The answer is to measure distance in a way a relay cannot fake: UWB ranging measures the signal's time of flight, and secure ranging modes protect that measurement cryptographically. Aliro's hands free mode uses Bluetooth LE plus UWB. Locks without UWB should require a touch on the lock or a deliberate action in the app.

Replay of weak radio protocols

Weak designs send the same unlock message every time, or use a counter without cryptographic binding. Matter sessions use authenticated encryption with message counters and Aliro uses asymmetric cryptography between phone and reader, so a recorded exchange cannot simply be replayed. Matter's Door Lock cluster also requires timed invokes for lock, unlock, user and credential commands, which bounds how long a command can be held back.

Shared code leakage

The most common failure is social, not technical. A guest code given to a contractor is never removed, or one family PIN is shared widely. The fix is in the data model the Door Lock cluster already supports: individual users, schedules, one time codes, and an audit log that shows which credential opened the door. Locks should also limit wrong PIN attempts; ETSI EN 303 645 provision 5.1-5 requires a mechanism that makes brute force attacks over network interfaces impracticable.

Account and cloud compromise

If an attacker controls the owner's account in the maker's app, they can often add themselves as a user. That is a cloud security and account security problem: strong sign in, alerts on new users and admins, and a local log on the lock that the cloud cannot rewrite.

Physical attack

A smart lock with a weak deadbolt, a short strike screw or a poor override cylinder is still weak. BHMA ratings and a reinforced strike address this; firmware does not.

What do the US Cyber Trust Mark, UK PSTI, ETSI EN 303 645 and the EU CRA require?

US Cyber Trust Mark

The FCC describes the US Cyber Trust Mark as a voluntary labelling programme for wireless consumer IoT products. Qualifying products will carry a logo and a QR code linking to a registry with details such as the support period and whether security updates are automatic. The FCC's page says it is still standing up the programme: the first lead administrator withdrew effective 19 December 2025, a new one took over effective 13 April 2026, and a filing window for label administrators opened on 11 August 2026. NIST IR 8425 is the practical baseline to prepare against.

UK PSTI

The UK regime came into effect on 29 April 2024 under the PSTI Act 2022 and its 2023 regulations, enforced by the Office for Product Safety and Standards. Passwords must be unique per product or set by the user, and unique passwords must not be based on incremental counters, public information or identifiers such as serial numbers unless derived with accepted encryption or keyed hashing. The maker must publish how to report security issues, with response timescales, and the minimum security update period with an end date.

ETSI EN 303 645

The most detailed of the four. For locks the provisions that bite hardest are 5.1 (no universal default passwords, brute force resistance), 5.3 (secure, timely, verified updates and a published support period), 5.4 (secure storage, tamper resistant identity, no hard coded critical security parameters in source code) and 5.6-4A on debug interfaces.

EU Cyber Resilience Act

The CRA applies to products with digital elements placed on the EU market, which includes connected locks. The European Commission's page states it entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026, and that the main obligations apply from 11 December 2027, with CE marking showing compliance. The Commission published practical guidance for manufacturers on 27 July 2026. The Commission's summary describes mandatory cybersecurity requirements covering the planning, design, development and maintenance of products, vulnerability handling during the product lifecycle, and third party assessment by a notified body for some products of particular relevance for cybersecurity. Its reporting page says that from 11 September 2026 manufacturers must report actively exploited vulnerabilities. For a lock maker, that turns ETSI style practices into legal duties, and the regulation text itself sets the detail on support periods and conformity routes, so read it rather than a summary before planning a product launch.

Where Safeguard fits, honestly

Safeguard does not test locks, analyse lock hardware, scan firmware images, run device management or generate hardware bills of materials, and its models are single purpose security models for software supply chain work. The fit is the software a lock maker builds. The firmware contains large open source stacks (an RTOS, Bluetooth LE and Thread stacks, the Matter SDK, a crypto library), and the companion app and cloud services behind accounts, guest codes and updates are ordinary repositories and container images. Safeguard can scan repositories, container images and SBOM files such as the SPDX documents a Zephyr or Yocto build emits, match components against vulnerability databases, rank findings with reachability analysis, enforce policies and gates, and open fix pull requests when a fixed version exists. It does not help with closed radio firmware from a chip vendor, the boot ROM, factory key ceremonies or the mechanical side of the lock.

Common mistakes

• Treating a smart retrofit lock as a stronger lock. It turns the existing thumbturn; the deadbolt, strike and frame are unchanged.
• Leaving guest codes forever. Codes should have an owner, a schedule or an expiry, and someone should review the list.
• Posting the Matter QR code. The setup passcode is the commissioning secret. Keep the label private, and if it has been exposed, factory reset and re-commission.
• Judging proximity by signal strength. Hands free unlock needs secure ranging or a deliberate user action.
• Shipping with debug ports open. A debug port left enabled at the factory can expose keys and firmware no update can protect.
• Signing with a key on a build server. The signing key is the root of every future update; put it in a hardware security module with approvals.
• No downgrade protection. Signed old firmware is still old firmware. Use version checks or a security counter.
• Depending on one cloud for every operation. Build or buy locks that keep local control through Matter and a keypad, and publish the support end date.
• Forgetting the companion app and cloud in security reviews. Many lock compromises would start there, not at the door.

FAQ

How does a smart lock work?

A small geared motor turns a deadbolt or thumbturn when the lock's microcontroller accepts a credential: a phone key over Bluetooth LE, NFC or UWB, a keypad code, a fingerprint, or a command from a hub or app over Thread or Wi-Fi. Sensors report bolt and door position.

Is a smart lock safer than a regular deadbolt?

Mechanically, it is only as strong as its deadbolt, strike and door frame, so check for a BHMA A156.40 residential deadbolt rating. Electronically, it adds audit logs, per user codes and remote alerts, and adds software risk that depends on the maker's update record.

What is a secure element in a smart lock?

A tamper resistant chip or protected area of the main chip that stores keys and runs cryptographic operations without exposing private keys. It protects the device identity and credential keys from extraction, but not from bugs in the firmware that decides when to unlock.

How do I add a smart lock to Matter?

Scan the QR code (starting MT:) or type the 11 digit manual code into your Matter controller app. The app finds the lock over Bluetooth LE, checks its attestation certificate, gives it an operational certificate and joins it to Thread or Wi-Fi.

What is Aliro?

Aliro is the Connectivity Standards Alliance's standard for phone and wearable access credentials. Version 1.0 was announced on 26 February 2026. It works over NFC, Bluetooth LE, and Bluetooth LE with UWB, and is aligned with the main phone wallets.

Can a smart lock be hacked?

Any connected device can have vulnerabilities. Realistic risks are relayed proximity unlock, weak radio protocols, leaked codes, account compromise and forced entry. Prefer a rated deadbolt, standard protocols and a maker with a published support period.

What happens to a smart lock if the company goes out of business?

Cloud features stop, and security updates end. A lock that supports Matter keeps local control through your other controllers, and a keypad and key keep working. Check the published support period before buying.

Do smart locks work without Wi-Fi?

Yes. Many use Thread or Bluetooth LE instead of Wi-Fi, and the keypad, fingerprint sensor and key work with no network at all. Remote access needs a hub or border router connected to the internet.

How long do smart lock batteries last?

It depends on the radio, how often the door is used and alignment. Thread and Bluetooth LE locks draw less than Wi-Fi locks that listen constantly, and a misaligned strike that makes the motor strain shortens battery life sharply.

What is ANSI/BHMA A156.40?

It is the American National Standard for residential deadbolts, developed by the Builders Hardware Manufacturers Association. Certified products show a ratings combination for security, durability and finish and appear in BHMA's certified products directory.

Fix it without waiting for upstream

A smart lock's firmware is mostly open source stacks (an RTOS, Bluetooth LE, Thread, Matter and a crypto library), and its companion app and cloud services pull new dependencies every week, so a fix published upstream has to reach both the firmware build and the services before it protects anyone. The steps below apply to those open source components and container images, not to the closed radio firmware or boot ROM a chip vendor supplies.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same flow fits a lock's companion app or the account and guest code services behind it, which are ordinary application repositories.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits a firmware team whose Zephyr or Matter builds run on its own build hosts and who want the scan to run where the build runs, against the SPDX files the build already emits.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. When an advisory names a Bluetooth host stack, a Thread component or a TLS library, the same conversation can look up which of your projects carry it.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

For more on the devices around your lock, see does Matter make a smart home secure, our smart home purchase checklist and how a keyboard is made, which covers the same Bluetooth LE pairing and firmware signing ideas in a simpler device.

Quick check

Sources

• Connectivity Standards Alliance, Matter
• Connectivity Standards Alliance, Matter Arrives (4 October 2022)
• Connectivity Standards Alliance, Matter 1.6 announcement (17 June 2026)
• Connectivity Standards Alliance, Aliro
• Connectivity Standards Alliance, Introducing Aliro 1.0: A Unified Standard to Transform the Access Control Ecosystem (26 February 2026)
• Connectivity Standards Alliance, announcement of the Aliro effort (9 November 2023)
• Connectivity Standards Alliance, Distributed Compliance Ledger
• Connectivity Standards Alliance, Product Attestation Authorities
• Matter SDK (connectedhomeip), SetupPayload.h
• Matter SDK (connectedhomeip), SetupDiscriminator.h
• Matter SDK (connectedhomeip), Door Lock cluster definition
• Matter SDK (connectedhomeip), chip-tool guide
• Matter SDK (connectedhomeip), OTA Requestor app README
• Google Home Developers, Matter primer: Commissioning
• OpenThread CLI, dataset commands
• Bluetooth SIG, Core Specification
• NFC Forum, Specifications
• GlobalPlatform, Specifications library
• BHMA, Product Grade Levels
• BHMA, home page and Certified Products Directory
• BHMA Secure Home, Choose Your Ratings Combination
• MCUboot, Design
• MCUboot, imgtool
• Zephyr Project, Additional Zephyr extension commands (west spdx)
• Zephyr Project, Building, Flashing and Debugging
• ESP-IDF Programming Guide, Secure Boot v2
• ETSI, EN 303 645 deliverables directory
• ETSI, EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements
• NIST, IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (September 2022)
• NIST, IR 8425 full text (PDF)
• NIST, IR 8259A, IoT Device Cybersecurity Capability Core Baseline
• FCC, U.S. Cyber Trust Mark
• FCC, Cybersecurity Labeling for IoT
• FCC, Equipment Authorization
• GOV.UK, The UK Product Security and Telecommunications Infrastructure (Product Security) regime
• European Commission, Cyber Resilience Act

Last reviewed: 24 October 2026.