Operational security · details
Security designed for everyday operations
Your sign-in credentials stay with you. Routine authentication with an issued card does not need the internet. Here is what to do if a connection fails, a card is lost or a password changes.
Credentials on your premises, specific services in the cloud
Sign-in accounts and passwords are stored on your computer or company server. are also stored locally and may include names and references to employees.
ChipLogin handles licences, delivery of initial keys for new cards, diagnostics and storage of . In the network variant, your company's creates a new authentication key when a card is issued and writes to the card. Subsequent sign-ins are verified within your environment.
When cloud services are used, operational logs and device status information are also sent. Diagnostic logs may contain workstation and identity identifiers. Audit history is verified using hashes; the text of the audit records is not sent for this purpose.
What operating without internet means
An internet or ChipLogin Cloud outage does not stop routine verification of an already issued card. In mode, the computer's service performs it; in Auth mode, the company server does. Cloud tasks, such as downloading material for new cards or sending audit hashes, require the relevant service to be available.
Loss of the connection between a workstation and company Auth is different: the network variant cannot perform a new card authentication without Auth. The Windows sign-in screen still offers the usual account and password option, provided the account's configuration and availability allow it. Local does not depend on a server; Windows sign-in and business applications still follow their own environment's rules and dependencies.
Licence validity and continued work
An expired licence does not block routine sign-in. The management interface shows the licence status and expiry date. Activating another device and obtaining a new licence are separate actions.
Disable a lost card
The employee reports the loss and an authorised administrator removes the card assignment or disables the relevant identity. At the next authentication within that management environment, the card can no longer release sign-in credentials. A replacement card can be assigned so the employee can continue using their account.
With central Auth, you make the change in one place. Independently managed local workstations have their own settings, which need updating. Blocking a card addresses its future use; if an existing employee session also needs to be ended, the administrator does so in the relevant system.
A forgotten card does not remove the password option
You can use the usual account and password option on the Windows sign-in screen. Access remains subject to the account's rules and availability.
A new password in Windows and ChipLogin
The employee changes their password using the standard Windows procedure. This changes the account password. ChipLogin needs the same current credential for the next sign-in: if Windows rejects the previously stored password, the asks the employee to enter a valid password.
After a successful sign-in with the current password, the component requests an update of the credential stored in ChipLogin. The card can then use the new password for future sign-ins. Changing the account password and updating its copy in ChipLogin are two consecutive steps; resetting a forgotten password is a separate administrative action.
Trace events and verify the history
The audit log shows the time, event type, computer, relevant identity and result. For denied access, it can also show the reason, such as an unknown card or a disabled identity.
The server-side auth.login event confirms authentication and release of sign-in credentials. Whether the account was ultimately accepted is checked in the Windows logs.
Audit records form a chain of hashes. Changes to their content or sequence are detected when the chain is checked. Hashes are also sent to a cloud witness, which keeps a reference for comparing the local history. It receives hashes, not the content of audit records.
Event: auth.login
Identity: Employee A
Workstation: WORKSTATION-A
Result: Denied
Reason: identity_disabled
Authentication was denied because the identity is disabled. This example explains the record structure; it is not an actual customer event.