Feature Request: Decouple Keypad Authentication from Lock Action for Alarm System Integration

Discussion
1

Hi,

I want to post a Feature Request, but don’t have the permission.

Here is my feature request:

Title: Decouple Keypad Authentication from Lock Action for Alarm System Integration

Product name

NUKI Smart Lock / Keypad 2 / Keypad with Fingerprint / Aliro-enabled access setup

Summary

Please add an optional mode where the NUKI keypad only performs user authentication, but does not directly unlock or lock the door. Instead, the successful authentication event should be exposed via API, webhook, or similar integration interface so external systems can decide what to do next.

Features

Add an optional configuration mode for keypad-based access methods such as fingerprint, PIN, NFC, or Aliro, where authentication is separated from the actual lock action.

In this mode, the keypad should only verify the user identity and then send an event such as:

  • User authenticated successfully
  • Authentication method used (fingerprint, PIN, NFC, Aliro)
  • Which user was authenticated
  • Which PIN or credential slot was used
  • Timestamp of the authentication
  • Whether the authentication was accepted or denied

This event should be available through:

  • Local API
  • Webhook
  • NUKI Bridge
  • Smart Lock event stream

The important part is that the authentication itself must be available as a distinct event before the door is unlocked.

This would allow external systems such as Home Assistant, alarm panels, or custom automation platforms to:

  • First disarm the alarm system
  • Then decide whether to unlock or open the door
  • Apply custom logic depending on the authenticated person
  • Optionally deny door opening even after successful authentication
  • Trigger different automations depending on the user or credential type

Ideally, this should be an optional feature and not replace the current direct-unlock behavior. Many users will still want the keypad to unlock immediately, but advanced users with alarm systems need a more flexible flow.

Reason

I have been using NUKI Smart Locks for many years and I am very interested in convenient access methods such as fingerprint authentication or, more recently, Aliro with an iPhone or Apple Watch.

However, I also use a proper alarm system with sensors on all doors and windows. This creates a major problem: if the door is opened directly by the NUKI keypad while the alarm system is still armed, the alarm will trigger immediately.

From a security perspective, I do not want to solve this by introducing entry delays. An entry delay means that an intruder is already inside the house before the alarm reacts. I want the alarm to trigger immediately for unauthorized entry, not several seconds later.

I also do not consider it reliable enough to react only after Home Assistant receives a “lock opened” event. That event may arrive too late, be processed too late, or in rare cases be missed entirely. In such a setup, the door sensor could already trigger the alarm before the automation disarms it.

The secure order should always be:

  1. Authenticate user
  2. Disarm alarm system
  3. Unlock or open the door

At the moment, I achieve this by using the outdoor keypad of my alarm system. After entering a code there, the alarm system is disarmed and its control panel sends a web request. In my case, this request goes to Home Assistant, which then decides whether to open, unlock, or lock the NUKI Smart Lock. This works, but it is much less convenient than using fingerprint or Apple Watch authentication directly on the NUKI keypad.

That is why I believe authentication should be available as a standalone event, independent from the lock action itself.

Examples

Here are some practical use cases for this feature:

  • A user authenticates with fingerprint on the NUKI keypad. Home Assistant receives the authentication event, disarms the alarm system, and only then sends the unlock command to the NUKI lock.
  • A user authenticates with Apple Watch or iPhone via Aliro. The system first disarms the alarm and then opens the door.
  • Different users trigger different actions. For example, if John authenticates, the system disarms the alarm and unlocks the door. If a cleaner authenticates, the system only unlocks during certain hours.
  • A specific PIN could be used only to disarm the alarm but not unlock the door automatically.
  • A child’s fingerprint could unlock the door only after checking time-based rules or presence conditions.
  • An automation platform could log exactly who authenticated and by which method.
  • A user could authenticate successfully, but the external system could still decide not to unlock the door because another condition is not met.
  • The event could be used to switch on lights, pause surveillance recording, or trigger a “coming home” scene before the door opens.
  • Security-conscious users could build a fail-safe flow where alarm disarming always happens before the door opens, instead of relying on lock-status updates after the fact.
  • Users with alarm systems and immediate-trigger door sensors could finally use NUKI keypad features without compromising either convenience or security.

This feature would make NUKI much more useful in professional and security-focused smart home setups, especially for users who need both convenience and strict alarm handling.

1 Like