Security
How a session is protected, and what is not done yet
The readable overview. The formal wording, written for whoever has to approve remote access software, is the security statement, and nothing here goes beyond it.
The shape of a connection
A number, then a password or a person
Every machine shows a nine-digit number and an access password. The password lets you straight in. Without it, the person at the machine is asked to allow you; with no answer in 60 seconds, the connection is turned away.
From release 0.6.0, the picture can be prepared early. When someone starts to sign in with a password or a remembered device, Nelkira may start capturing the screen into memory before the sign-in is checked, at most once every 30 seconds; nothing leaves the PC until the caller is let in. On the normal desktop, the first picture also waits until Nelkira has asked for the Screen shared pill to be shown, for at most 0.3 seconds.
Direct where the network allows
A session tries the local network and a relay at the same time and keeps whichever answers first. Two PCs on the same subnet normally talk straight to each other where Windows Firewall allows it, and the session stays on the site; the relay still hears about the call while it is set up.
A relay on port 443 where it does not
Where a firewall refuses a direct path, the session goes through a relay on port 443. Neither machine needs a public address or a forwarded port.
Distance to the relay decides how a relayed session feels. We measured a Kansas relay from Dhaka once: 216 ms each way, roughly 430 ms between moving the mouse and seeing it move on the far screen. A relay in Dhaka, for a session in Dhaka, measured about 75 ms. Today Nelkira’s relay is in Mumbai, India. You can run your own: Setup’s /RELAY option points a PC at it, as the self-hosting guide says. Said plainly: sign-up, downloads and updates still come from nelkira.com.
Keys agreed between the two machines
The two ends agree their keys with each other before anything else is sent. A relay is handed encrypted bytes and nothing more.
Where the keys live
The two machines agree a key with each other, fresh for every session, using an elliptic-curve exchange (P-256). Everything after that is encrypted with AES-256-GCM: screen, keystrokes, mouse, clipboard and files. Each direction has its own key, and a counter stops a captured message being replayed.
A relay copies encrypted bytes and holds no key that would let it read them, ours included. A hostile relay can still sit in the middle of a sign-in in two cases, set out here and under Disclosures below.
Encryption alone would not stop a relay from running two exchanges and sitting between them. So, where a password is used, both ends prove it to each other from release 0.4.0 (SPAKE2, RFC 9382), bound to the two keys they saw, and the password itself is never sent. A viewer older than 0.4.0 still runs the check one way: it sends the password, inside the encrypted channel, to whichever machine answers the number, so a sign-in from an older viewer through a hostile relay is not protected against impersonation. A 0.4.0 viewer never sends the password to a PC on an older Nelkira; there it offers only the Allow way in until that PC is updated.
Notice dated 22 October 2026. From 1 May 2027, a PC running Nelkira 0.4.0 or newer accepts a password only from Nelkira 0.4.0 or newer (Windows, Linux, macOS and Nelkira Go). Older viewers can still connect when the person at the PC clicks Allow. Update before then at nelkira.com. Until your viewer is updated to 0.4.0, the password still travels inside the encrypted channel to whichever machine answers your number.
Release 0.4.1 reaches PCs in stages; the download page shows the version on offer.
What the accessed machine keeps
Every machine keeps its own record of what was done to it. When a session started, how it was authorised, and when it ended. Files taken or placed, and their names. Clipboard transfers by size, screen switches, Ctrl+Alt+Del, and the times the screen was blanked. Failed attempts are limited, and written to the same record.
The record never contains content. No clipboard text, no file contents, no keystrokes, no screenshots. It lives on the machine that was accessed, not on the engineer’s laptop. Evidence of what was done to a computer belongs to whoever owns it.
Remembered devices are tokens, not stored passwords: the machine keeps a fingerprint (hash) of a random token and the value it checks that device’s proof against, never the token itself. From 0.4.0, a remembered device unused for 90 days is dropped, and forgetting remembered devices on the PC (all at once, from the Advanced tab) invalidates their tokens. From release 0.4.1 the access password is a new one each time Nelkirastarts (unless the owner set a fixed one with the Agent__AccessPassword setting), and a new password does not forget remembered devices. Stored secrets are encrypted at rest with the operating system’s protected storage, apart from the registration token, which is a plain file. Where Nelkira is installed for use while someone is here, that does not keep them from other Windows accounts on the same PC: anyone signed in there can read and change the remembered devices, the registration token and, from 0.4.0, the device key that proves the machine’s number to the relays; and the access password too before release 0.4.1, which keeps the password it makes only in memory. On a PC set up for access when nobody is there, only administrators and Windows itself can open them.
What the person at the desk sees
An amber pill while someone is connected
For as long as someone is connected, a ‘Screen shared’ pill sits at the bottom right of their screen. Their own Nelkira window says ‘1 person is connected to this machine’. The pill is not shown on the Windows lock, sign-in, Ctrl+Alt+Del and administrator-prompt screens.
Their say over who gets in
They approve connections that arrive without a password, can end any session, and can forget every remembered device. Ending a session does not stop someone with the password or a remembered device connecting again. From release 0.5.0, Stop sharing keeps everyone out, remembered devices included, until someone at the PC presses Start sharing, also across restarts and updates.
Privacy screen has rules
Blanking the screen hides a session from people walking past. It blocks local input only where Nelkira runs with administrator rights or, from release 0.5.0, on a PC set up for access when nobody is there. Using it to hide from the machine’s own user breaches the Acceptable Use Policy.
Disclosures: what is not done yet
No certification, no audit
No ISO 27001, SOC 2 or HIPAA attestation. No third-party audit, and no formal penetration test yet: Nelkira has been internally security-tested only. When an outside test is done, we will say who did it and what they found.
The record is not tamper-evident
It is a plain file that anyone with a Windows account on the machine can alter or delete (from release 0.5.0, on a PC set up for access when nobody is there, only administrators can). Signing it, or sending it somewhere the machine cannot reach, is intended and not done.
Allow without a password has a limit
A connection approved by clicking Allow, with no password typed, is encrypted but not proof against an active attacker in the relay path. There is no shared secret to bind the key exchange to.
A password from an older Nelkira has a limit
A viewer older than 0.4.0 still sends the password, encrypted, to whichever machine answers the number, so a sign-in from it through a hostile relay is not protected against impersonation. A 0.4.0 viewer does not send the password to an older PC and asks for Allow there instead. From 1 May 2027 a PC on 0.4.0 or newer accepts a password only from 0.4.0 or newer viewers; older ones still connect when the person at the PC clicks Allow.
Other Windows accounts can read and change its secrets
Anyone with another Windows account on the same PC can read and change its remembered devices, registration token and, from 0.4.0, its device key, and its access password before release 0.4.1. From 0.4.1 the password Nelkira makes is kept only in memory. That is where Nelkira is installed for use while someone is here; on a PC set up for access when nobody is there (from release 0.5.0) only administrators and Windows itself can open its files, so shared PCs should use that. A fixed Agent__AccessPassword stays readable by every account that can read where it is set, including beside Nelkira.exe on a PC set up for access when nobody is there.
Unattended needs someone signed in, or the setup for it
Installed for use while someone is here, which is what Setup does unless told otherwise, a PC can be reached while someone is signed in to Windows and Nelkira is running. After a restart, a PC installed for use while someone is here waits until someone signs in. From release 0.4.1 it then has a new access password, so unattended access after a restart needs a remembered device or a fixed password the owner set with the Agent__AccessPassword setting, and from release 0.5.0 a pause made there with Stop sharing still holds until someone presses Start sharing. From release 0.5.0 an administrator can set a PC up for access when nobody is there, at the PC’s own console only, not over Remote Desktop. After a restart, a device that connected once with the password and Remember ticked can then reach it, at the sign-in screen too, unless someone at the PC pressed Stop sharing, which from release 0.5.0 lasts across restarts and updates until someone signs in there and presses Start sharing. The password is new after a restart and nobody can read it until someone signs in, so tick Remember beforehand. At the lock screen and at administrator prompts, the password currently shown to the signed-in person also works.
Set up for access when nobody is there: what changes
From release 0.5.0, through Setup’s Yes, which needs an administrator’s approval, or an IT rollout. A PC installed for everyone with release 0.4.x is set up this way when it is updated to 0.5.0, only after Setup has listed what changes and someone at the PC has chosen Install for everyone; Cancel, or an update that runs quietly, leaves it on 0.4.x. A helper who connects can answer Windows administrator prompts, with administrator rights when the person signed in is an administrator. A session let in with Allow, with no password, follows the same person into administrator prompts but ends at the lock and sign-in screens. A picture of the lock, sign-in, Ctrl+Alt+Del and administrator-prompt screens is not certain: on a test virtual machine without Direct3D 11, the sign-in screen and an administrator prompt were seen but a signed-in person’s lock screen was not (the Ctrl+Alt+Del screen was not tried), and none of it has yet been checked on a physical PC. Nelkira lets a helper send Ctrl+Alt+Del. This changes one Windows setting; uninstalling puts it back, and your organisation’s Group Policy, if it sets it, still decides. On a PC set up for access when nobody is there, only administrators and Windows itself can open Nelkira’s files; administrators can still read them. The screen locks when the last helper disconnects, and the ‘Screen shared’ sign is not shown on the lock, sign-in, Ctrl+Alt+Del and administrator-prompt screens.
The installer is not code-signed
Windows SmartScreen asks before it runs. Check the SHA-256 on the download page until that changes.
Each item is stated formally in the security statement, which is kept current. Where this page and the statement differ, the statement is right.
Found a weakness? Write to security@nelkira.com. We acknowledge within 3 working days, and take no legal action against honest research done in line with the vulnerability disclosure policy. There is no paid bounty today.
Three questions
Can Nelkira staff see my screen?
No. A relay, ours included, holds no key that would let it read what it carries. The limits, for a relay changed to attack sessions, are described above.
Is a session safe without a password?
It is encrypted either way. Without a password there is no shared secret to bind the key exchange to, so an active attacker in the relay path is not ruled out. With a password, both ends prove it to each other from release 0.4.0 (SPAKE2, RFC 9382) and the password is never sent. A viewer older than 0.4.0 still sends the password to whichever machine answers, so the same limit applies to it; a 0.4.0 viewer asks for Allow instead of sending the password to an older PC.
Is Nelkira certified for hospitals?
No. There is no ISO 27001, SOC 2 or HIPAA attestation, and no third-party audit yet. Where we claim one, we will publish the certificate.