Convenient access for employees.
Control for you.

You decide who can access computers, machines and areas connected to ChipLogin. Block lost cards and look up access events in the records. Communication is encrypted, and access data stays on your network.

Discuss our requirements What this means in practice
Audit trail · hash chain Demo
07:58:12 LOGIN · Station 03 OK
09:31:04 AUTHORIZATION · Machine 04 OK
09:47:51 DOOR · Hall A OK
10:12:37 LOGIN · Station 07 DENIED
Signed · chained

Everyday situations you need to handle

What should I do if a card is lost?

With shared management, block the card in ChipLogin Server and assign a replacement. On standalone computers, revoke access on each relevant device. For disconnected devices, changes depend on how permissions are updated.

How do I change an employee's permissions?

Update permissions through shared management. When an employee changes role, adjust their access to the connected computers, machines and doors.

What can I find in the records?

Find out whose card was used, when, at which device and with what result. Review granted and denied access together.

Where is the data stored?

With shared management, ChipLogin Server stores access data and records on your network. Details of record integrity verification are available below in the audit trail section.

Technical security details

Devices verify each other using certificates. The following overview is intended for your IT team.

Mutual TLS, everywhere

Every station, reader, and control unit has its own X.509 certificate and authenticates the server just as the server authenticates it. The mTLS connection rejects devices that cannot present a trusted certificate.

Device-generated private keys

Each device generates its private key locally and is designed to keep it on that device, so copying application files alone does not reproduce the station's mTLS identity.

Visual verification of new devices

When a new station registers, the administrator confirms its identity by eye using a visual fingerprint (drunken-bishop randomart) — the same principle OpenSSH uses to verify a host key.

Card authentication

ChipLogin supports MIFARE DESFire cards. We will assess whether your existing DESFire cards can be used.

DESFire card support

We support MIFARE DESFire with cryptographic verification. A readable card number alone is not enough. Before using existing cards, we check their configuration and suitable readers.

We never trust the card alone

A UID alone does not grant access. The card must pass cryptographic verification and be assigned to a user with the relevant permission. A copy of the card number cannot replace that proof.

We verify the card's authenticity

DESFire lets the system verify that a card holds the correct secret key, rather than just reading its number. Cryptographic verification is part of the solution, not an optional extra for doors alone.

Three encryption layers running at once

It isn't one "encryption" — it's three independent locks stacked on top of each other. Breaking one doesn't open the other two.

A visualization of the three independent encryption layers protecting communication between the card, reader, ChipLogin service on the station, and the authentication server

Layer A — the channel (mTLS)

Before a station and server exchange application data, both sides verify each other with their own certificate. A device without the corresponding trusted certificate and private key cannot complete that mTLS authentication.

Layer B — the card (DESFire, challenge-response)

The card never reveals its secret key, only proves it knows it. The server sends a random challenge, the card computes it with its key, the server verifies the result. An intercepted response is useless the second time — the next challenge will be different.

Layer C — the password (ECIES, sealed for one use)

Once the card proves its identity, the server encrypts the Windows password exclusively for a one-time key the station generated just for this attempt. Only it can decrypt it — and only right now. A plaintext password never travels over the network.

Want the full step-by-step technical breakdown? →

What happens under attack

Concrete scenarios, not vague promises.

Someone copies a card's UID with a cheap copier

The server recognizes the card can't answer the cryptographic challenge because it doesn't know the secret key — rejected immediately as an unknown card, before any sensitive data is exchanged.

Someone eavesdrops on the network between a station and the server

Passive network capture exposes mTLS-encrypted traffic rather than plaintext. The password payload is additionally sealed to the station's one-time key for that login attempt, which also limits replay of a captured payload.

Someone steals or takes apart the computer next to a machine

There's no stored password to find. Passwords live on the server — on the station, they exist in memory for only a fraction of a second during login itself.

Someone steals an entire station along with its certificate

The administrator blocks the station on the server just like a card — from that moment, the server rejects any request bearing its certificate, even if the attacker powers the computer on.

Someone impersonates the auth server on the network

The station rejects it at the mTLS level already — it doesn't have a valid certificate the station recognizes as the real server.

An employee loses their card

The administrator blocks or revokes the card in the system — a pure database operation, with nothing to change on the stations.

An audit trail you can trust

Every login, machine authorization, and door event becomes one signed record.

Cryptographically signed

Every event — a login, a machine authorization, a door unlock or denial — gets written to the log and signed the moment it happens.

One format for every endpoint

Windows logins, machine authorizations, and door events all land in the same log, with the same structure — no merging export formats from three different vendors before an audit.

The server stays under your control

The log itself lives on your ChipLogin Server, on your network — no copy of your access data sitting in a third-party cloud.

Detects tampering, doesn't just log it

Every record carries the hash of the one before it, so later alteration breaks the verifiable chain. Its fingerprint is also periodically anchored with an independent witness (ChipLogin Cloud), which receives a one-way fingerprint rather than the record content. Together these mechanisms are designed to make retrospective changes detectable.

Where we are today

The mTLS device architecture, visual verification, and audit logging described above run across the entire ChipLogin platform — ChipLogin for Windows, ChipLogin for Machines, and ChipLogin for Doors all share the same identity layer and the same server.

Have a specific security question — key rotation, certificate lifecycle, deployment topology? Request a technical consultation below.

Let's discuss security in your operation

Tell us what you need to verify. You do not need technical specifications to start. We will work through the details with you and your IT team.

Contact directly

Jakub Skoumal · Sales

jakub.skoumal@netajo.cz +420 602 295 875

or use the form below ↓

Please enter your name
Please enter a valid email
Please enter a message

By submitting this form, you agree to the processing of your data for the purpose of handling your inquiry, as described in our privacy policy.

Thank you. We have received your message.

We will get in touch to discuss the next steps.