A laptop fingerprint sensor unlocks the laptop and usually stops there. Immurok wants to do quite a bit more than that.
It is a tiny wireless box that can unlock your desktop session, approve a sudo command, authenticate via polkit, log you into a server over SSH, generate TOTP codes for 2FA, and put a physical touch in front of an AI coding agent. And it does all of that with the same finger, over Bluetooth.
The good news is that the core features work. The less good news is that on Linux, getting there was not as simple as touching a sensor. During my testing I ran into bugs, missing prompts, confusing behaviour, and one timing issue that made the initial setup a little challenging. But once things were setup, the device worked smooth and that's what matters, right?
Let's take a detailed look at what Immurok gets right, what still needs work, and whether this little box could earn a place on your desk.
I also have a video review of Immurok, if you prefer watching over reading.
What Immurok actually does
At its simplest, Immurok is a wireless fingerprint reader for a desktop or a laptop that does not already have one. But the feature list goes well beyond unlocking a screen.
You can use it to unlock an existing desktop session. Through Linux PAM integration, it can approve sudo and other supported authentication prompts such as polkit. It can generate and store SSH private keys on the device itself, and it can release a TOTP code only after it recognises your fingerprint.
Then there is the more unusual usage: AI-agent approval. The idea is that a coding agent can prepare a privileged command, an SSH operation, or a request for a secret, but it cannot complete the protected action until you physically touch the sensor.
According to Immurok, fingerprint templates and private keys stay on the device. There is no cloud account and no telemetry. Pairing uses P-256 ECDH with HMAC-SHA256, and authentication responses are cryptographically signed.
Those are the company's security claims, and as I said above, this review tests how the device behaves in use rather than auditing that cryptography.
The hardware
The hardware makes a good first impression. Here is what you are getting.
| Spec | Detail |
|---|---|
| Processor | RISC-V, up to 60 MHz |
| Connectivity | Bluetooth Low Energy |
| Sensor | Capacitive fingerprint, under 500 ms claimed recognition |
| Dimensions | 44 x 44 mm, 14.2 mm thick |
| Weight | ~40 g |
| Body | CNC aluminium |
| Battery | 110 mAh, USB-C charging |
| Standby draw | ~50 µA claimed |
| Fingerprint slots | Up to 5 authentication fingerprints |
There are controls at the back for power and for actions such as pairing or confirmation. The silver finish, rounded corners, and proportions make it look like a tiny Mac mini. That is not a complaint and even works well for people in the Apple ecosystem. It is neat enough to sit on a desk without looking like a random security dongle.
My review box contained only the device. There was not even a USB cable and I am not complaining. The battery life is pretty good, so charge is needed like once a month and type C cable is in every household, I presume.
Immurok claims more than a month of normal use per charge. When I started testing, the Linux TUI showed 84% battery on the first run. After roughly a week, it was at 78%, so about 6 percentage points in that period. That looks promising for the month-long claim, but one week is not enough to confirm it, especially since battery-percentage readings are not always perfectly linear.
Installing on Linux means building it yourself
Windows and macOS get graphical applications. On Linux, the version I tested used a Rust daemon, a command-line client, and a terminal user interface. There was no equivalent graphical management app and no easy-to-install binary as well.
On my Ubuntu 26.04, I first installed the required development and runtime packages, then Rust through Rustup. The make check-deps command was helpful here, because it listed the missing components instead of making me discover them one build error at a time.
Then came the first Rust build, with around 200 crates to download and compile. It kept the CPU busy and produced plenty of warnings, though these were warnings and not compilation failures.
After that, make install was fairly quick. It installed the daemon, the command-line tools, the PAM module, the authentication helper, and the system integration, and the user-level daemon was already running when the install finished.
For an experienced Linux user, this is all doable. But for a device that presents itself as a simple replacement for typing passwords, it is too much friction. Before this ships to general users, Linux needs straightforward packages for the supported distributions and a much clearer first-run flow.
Pairing: connected is not the same as paired
The first pairing attempt immediately showed how early the software was.
I powered on the device and tried pairing from the TUI. It said the device was not connected. The CLI told me to press the device button within 30 seconds, but then failed immediately. It did not wait for 30 seconds at all.
What eventually worked was connecting Immurok manually through Ubuntu's Bluetooth settings first. Once the operating system showed it as connected, I went back to the Immurok TUI, pressed p, and then pressed the button on the device. It exchanged keys and reported that pairing had succeeded.
So there are two separate states here: connected over Bluetooth, and paired inside Immurok. That distinction may be technically reasonable, but the application never explained the required sequence when I actually needed it.
The product should walk you through this step by step, including the LED state, the operating-system connection, the Immurok pairing action, and the button press.
Enrolling fingerprints
Once the device was connected and paired, enrolling the first fingerprint went more smoothly.
In the TUI, I pressed e, placed my finger on the sensor, lifted it, and repeated. My test firmware asked for 12 captures before it enrolled the finger in slot zero.
The device supports up to 5 normal authentication fingerprints, and when you add more after the first one, an existing authorised finger has to approve the new enrolment. That is a sensible security requirement, but again, it needs to be stated clearly on screen.
The command line interface is finiky at times. At one point, trying to enrol again failed because the fingerprint was already present, and a deletion attempt simply failed without explaining why.
The bug that stopped sudo from working
With a fingerprint enrolled, I tested sudo apt update. Nothing happened. Touching the sensor did not authenticate me, even though the fingerprint was clearly there.
The problem turned out to be a race in the Linux daemon. When the Bluetooth session began, the daemon immediately asked the device for its status. But a Python notification helper was still starting up its D-Bus connection. On my machine, that helper took about 5.2 seconds to become ready, while the status request timed out after 5 seconds. That tiny difference left the daemon with no device status for the rest of the session, which showed up as NO_STATUS.
Since I had installed Claude for testing the agent specific features of Immurok, I let it handle the issue and it fixed that by increasing the limit to 15 seconds.
After rebuilding and installing the patched version, sudo authentication worked. I ran the command, touched the sensor, and it continued without asking me to type the account password.
It is a good thing that the code is open enough to inspect and fix. But this was also a basic authentication path failing because one helper started a fraction of a second slower than expected. These things should be fixed before the mass release.
Unlocking Ubuntu, and why fallback matters
With the patched client, Immurok could unlock an Ubuntu session that I had already logged into and then locked. I touched the sensor and the desktop opened.
It did not work at the very first login screen after powering on the computer, though. That is intentional behavior applicable to macOS and Windows too. The user-level service is available for unlocking an existing session, but the initial login still needs the normal account password. This distinction matters, because "screen unlock" can easily sound like "replace your password at every login," and they are not the same thing.
The fallback behaviour was good. When I disabled Bluetooth or disconnected Immurok, sudo and login did not leave me waiting for a fingerprint device that was no longer there. They went straight to the usual password field. That is essential. A convenience device should never turn a temporary Bluetooth glitch or a flat battery into a lockout.
SSH keys are the highlight
SSH is where Immurok starts to become more interesting than an ordinary fingerprint reader.
It can generate an ECDSA P-256 SSH key on the device. The private key stays there, and you export only the public key to place in the remote server's authorized_keys file.
ECDSA is a practical choice here because it can deliver security comparable to RSA using much smaller keys. That means less storage, less data to transfer, and lower processing overhead, making it suitable for a small battery-powered device.
The first time I generated a key through the CLI (not the TUI), it appeared to just stop. The missing piece of information was that Immurok was waiting for my fingerprint authorization. There was no prompt telling me to touch the sensor, and no useful feedback when I did. I only knew what to try because I had already been digging into the behaviour. Once I touched the sensor, the key was generated.
If an action requires physical authentication, the interface has to say so. The TUI was better here. When I generated another key there, it explicitly told me to touch the sensor to authorise the action, and the key then appeared in the next slot.
I exported the public key, added it to my Raspberry Pi Pironman Max, and enabled Immurok's SSH takeover. This adds the Immurok agent socket as the SSH IdentityAgent, which gives the device-backed keys priority.
When I connected to the Pi, Immurok asked for my fingerprint, I touched the sensor, and the SSH login succeeded.
Importantly, my normal SSH setup was not destroyed. Existing keys on the computer stayed available as a fallback, so when I connected to a server that did not have the Immurok public key, SSH just continued using my existing key.
That is the right approach. You can introduce Immurok gradually instead of forcing every server to change on day one.
You can delete keys through the TUI after fingerprint approval, or through the CLI, though the CLI again failed to show the required fingerprint instruction during deletion. You can also import an existing private key onto the device, but with two limitations.
Import was only available through the CLI in my tested version, and it accepted only ECDSA P-256 keys. If your existing key is Ed25519, RSA, or another format, you cannot simply move it over to Immurok.
TOTP just works
Immurok can also hold TOTP secrets, and this was one of the smoother experiences.
I added a GitHub TOTP entry, went into Immurok TUI, and then requested a code. Fetching the code required another fingerprint touch. I entered that code into GitHub, and it worked.
This is a simple feature, but a useful one. The TOTP seed is not sitting in a general desktop authenticator, and someone using your unlocked computer still needs your fingerprint before Immurok will release a code. As always, recovery codes still matter. If the device is lost, damaged, discharged, or reset, you need another way into the account.
Putting a fingerprint in front of an AI agent
The most distinctive pitch is using Immurok as a human-in-the-loop control for AI coding agents.
I installed the Immurok plugin for Claude and activated it for the project. Immurok also provides an imk wrapper that can launch a command in agent mode. In one test, the agent tried to connect to my Raspberry Pi over SSH, Immurok requested fingerprint verification, and after I touched the sensor, the agent connected to the Pi.
The idea is that even if the computer is unlocked, the agent cannot complete a protected wrapped action while you are away from the desk.
But there is an important limitation: this is only a gate if the action actually goes through the gate. Project instructions may tell an agent to use imk, and a plugin may make that tool available, but an ordinary command can still take the normal route if the wrapper is bypassed. My earlier Git push did exactly that, because it was not wrapped.
So this is not automatic enforcement just because a file tells the agent what to do. A serious setup has to arrange for sensitive operations to always run through imk run --agent, or to enforce the protected path at a lower level. Immurok can provide a valuable physical approval mechanism. It cannot secure a workflow that still leaves an unprotected path open right beside it.
Things that could be better
Even with the core features working smoothly after the setup, a few rough edges are worth calling out clearly. None of these are dealbreakers on their own, but together they are the difference between "promising" and "ready."
The TUI and CLI need serious polish
The Linux TUI brings together the dashboard, keys, PAM integration, logs, firmware updates, and settings. It shows connection state and battery percentage, and for most tasks it communicates better than the CLI does.
The CLI version lacks tab completion, which made nested commands harder to discover. Pairing claimed it would wait and then failed. Failed enrolment and deletion did not give useful explanations, and SSH import lived only in the CLI while other actions were easier to follow in the TUI.
Documentation is not optional for a tool like this. Immurok touches PAM, Bluetooth, SSH configuration, private keys, TOTP, etc. The GitHub README has details, but buyers need a stable setup guide, clear in-app prompts.
The log file that never stops growing
There is one smaller issue that gets bigger with time. The daemon continuously writes to ~/.immurok/logs.txt. After about a week, mine had reached roughly 4 MB. After 2 weeks, it is 15 MB.
At a steady rate, that is closer to 200 MB a year than multiple gigabytes. But the real problem is that the file looks unbounded, and a persistent reconnect loop or a recurring failure could make it grow much faster. The application needs log rotation with a sensible size and retention limit.
On Linux, sending routine logs to the journal would make far more sense than quietly maintaining an ever-growing private text file.
Is Immurok worth it?
After more than a week, I am more than happy to use Immurok as a daily driver. The trouble was mostly at the initial setup stage, and I am way past that now.
I liked the fingerprint reader on my Dell XPS in the past. My present laptop, Asus Zenbook, doesn't have one, so the Immurok fingerprint reader complements it very well.
The hardware is attractive, compact, and useful, and the core features work well. I used a fingerprint to approve sudo, unlock an existing Ubuntu session, authenticate an SSH connection to a Raspberry Pi, retrieve a working GitHub TOTP code, and approve an agent-run SSH action.
I also like the fallback design. A disconnected device did not block password login, and servers that were not configured for the Immurok key kept working with my existing SSH keys.
The hardware works great and the software on Linux needs upgrade. Source code build should not be forced onto users in 2026. The CLI needs to be better at showing the appropriate feedback message.
I have already seen two firmware updates and there is a software update already on their repo. So, it's just a matter for software updates and the device would become suitable for even the beginners.
So, if you think that the device suits your workflow and it doesn't dent your budget, you can opt for Immurok.
✅ Private keys and fingerprint data stay on the device, with sensible password and key fallback
✅ Compact, well-built aluminium hardware with promising battery life
❎ Linux install means building from source; there is no packaged app yet
❎ The CLI is buggy, TUI is okay. Docs need to be included. Software update should fix the issue.
Getting Immurok fingerprint key
At the time of writing this article, Immurok is still in crowdfunding. It is available through Kickstarter for $59 US, with a stated retail price of $69 and estimated delivery in November 2026.
Please readhe their terms and conditions on shipping, custom fee and return policy.
I tested the pre-release review unit and the software is already changing quickly. The version shipping to backers is still a few months away, so there is time for the Linux experience to improve before customers receive the device. I do hope the installation, pairing, prompts, documentation, and reliability are all much better by November.
For now, I am happy to have Immurok on my desk.
from It's FOSS https://ift.tt/tD79U1v
via IFTTT
