Support & frequently asked questions.

It is a standalone .NET library that plugs into the Windows logon screen via Microsoft's Credential Provider API. Where Windows ships with a single password tile, CodeB adds a tile that accepts NFC cards, RFC 6238 TOTP codes, X.509 PKI smartcards and USB memory tokens — and it can replace the password tile entirely when policy demands it.

Most MFA tools sit on top of an existing password logon. CodeB is the logon itself. It implements the ICredentialProviderCredential2 interface and ships with an integrated Credential Provider Filter, which means it can hide the Microsoft Password Provider tile rather than just adding a second factor next to it. That distinction matters at audit time.

Either, or both. CodeB supports local accounts, Active Directory accounts and Microsoft Entra ID accounts on the same workstation. Hybrid environments are the most common deployment shape we encounter.

Two add-ons travel with the CP V2 licence at no extra cost: CodeB Web SSO, a managed browser extension for Edge and Chrome that fills usernames, passwords and TOTP codes into web apps (and into legacy Windows / Java apps such as T2med) without ever exposing credentials to page JavaScript, and CodeB Desktop Switcher, a hotkey-driven tool that swaps your desktop files, icon positions and per-monitor wallpapers for a clean profile before you share your screen. Either can be licensed standalone if you already use a different desktop logon stack.

The Credential Provider V2 ships with native support for NFC cards based on MIFARE and DESFIRE, RFC 6238 TOTP codes, X.509 PKI smartcards and software certificates, and plain USB memory sticks for evaluation. Beyond that, a wide library of NFC tokens is supported — including national identity cards, transit cards, bank cards, and the wider DESFIRE family.

Issue them a USB memory token for evaluation, or use any RFC 6238 TOTP app — the same identity can log in to Windows whether the card is present or not.

Yes. A common pattern is a primary NFC card plus a TOTP app on a phone as a backup for the days someone leaves the card at home. There is no extra licence cost for additional tokens per identity.

Both patterns are equally supported and in practice our customers split roughly 50/50 between them.

• Pattern A — second factor. Keep the existing Windows password and add the NFC card or TOTP code as a second factor on top of it. Multi-factor logon.
• Pattern B — passwordless. Drop the password entirely and let the NFC card or TOTP code carry the logon on its own.

Same software, same tokens; you switch between them with policy. Regulated environments where the password is a known risk usually go passwordless; environments that already have established password hygiene typically add CodeB as a second factor first and migrate to passwordless later. We will help you decide which pattern fits your environment.

Yes. This is the classic shop-floor pattern — short auto-lock, mobile operators moving between workstations, no time or willingness to type a PIN. The Credential Provider V2 supports it natively for MIFARE Classic 13.56 MHz cards (and the wider MIFARE / DESFIRE family). End-to-end setup takes roughly ten minutes per machine.

1. Download codeb_smartloginhelper.zip from www.aloaha.com/downloads/codeb_smartloginhelper.zip and extract it on the target workstation.
2. Run CredentialProviderInstaller.exe and click “Install Credential Provider”. This registers CodeB with the Windows LogonUI.
3. Install your licence key with SmartLoginLicensing.exe.
4. Link the operator's Windows account to the card with LinkNFCCard.exe. Leave the PIN field empty — this stores the default PIN 0000 against the card.
5. At the Windows logon screen, the operator taps the card and leaves the PIN field empty. The default PIN 0000 is applied automatically, so the card becomes the sole authentication factor. One tap and they're in.

A quick security note: card-only login means the card is the credential. Loss of the card equals loss of access until you unlink it, so this pattern pairs naturally with a short inactivity lock and a lightweight card-issuing process. In environments where that trade-off isn't acceptable, keep the PIN field on — the same software supports card + PIN as two-factor login with no reinstall.

Yes. The Credential Provider V2 sits inside the Windows LogonUI as a first-class credential provider, which means it works with any account model Windows itself understands — local accounts, on-prem Active Directory domain accounts, hybrid Azure AD-joined machines, and Entra ID (Azure AD)-joined machines. The credential provider hands the resolved credential to Windows; Windows validates against the account model it's configured for. Shop-floor Windows 11 machines joined to Entra ID with operator accounts are a very common deployment.

Yes. A single Windows domain account can have many cards bound to it — the classic shift-work and shop-floor pattern. Each operator carries their own physical card; all cards resolve to the same Windows session. Enrolments scale to thousands of cards per fleet, and the pattern is in production use in environments with 2,000 + card holders sharing operational accounts.

The CodeB Credential Provider 2 supports every Windows edition from Windows 8 onward, including Windows 8.1, 10, 11 and the corresponding Windows Server releases up to Server 2025. Pre-Windows 8 systems are out of scope for the current Credential Provider V2 build.

CodeB ships as a command-line installer. An MSI package is available on request. The Credential Provider configures via registry policy, so any tool that can write to the registry — Group Policy, SCCM, Ansible, PowerShell DSC, hand-crafted .reg files — can deploy it. We do not currently ship our own ADMX templates; the registry keys are short and documented in the install guide.

Yes. A separate command-line utility, CodeB Admin CLI (CodeBAdminCLI.exe), automates everything the GUI helpers do: linking a card serial to an Active Directory user as a second factor, storing encrypted credentials in AD or as a local soft-token, listing assignments, and revoking cards. It takes /user, /domain, /serial and /pin (plus /password for credential storage), so a CSV plus a PowerShell loop covers a full rollout. Download it from www.aloaha.com/downloads/CodeBAdminCLI.zip. Full reference and switches on the products page. Works against both local accounts and AD. With AD permissions delegated correctly, no local administrative privileges are required.

No internet connection or cloud service is required. Every component — the Credential Provider, the audit log and the Web SSO endpoint — runs on your own infrastructure. There is no SaaS control plane to authenticate against. The product is deployed and used regularly in fully air-gapped defence and OT networks where an internet connection isn't available at all.

Both storage back-ends behave identically at logon; the choice is largely a matter of taste. A shared folder wins on simplicity: no Active Directory changes, permissions live on the file share, works instantly in labs and small deployments. Active Directory storage wins on elegance in larger fleets: card data travels with the user object, no separate share to reach, no separate ACL to manage. Same software, same tokens; you can switch the back-end later without reissuing cards.

One attribute permission. The altSecurityIdentities attribute on the user object needs to be readable and writable by Domain Computers (which effectively means LocalSystem on the joined workstation). Ideally the user account itself also has read/write on its own altSecurityIdentities. That is the only AD change required. Once the permission is in place, LinkNFCCard.exe writes to altSecurityIdentities directly and reports a confirmation on success — or a warning if the permission is missing.

In LinkNFCCard.exe, tick “Store Data in AD” — and typically also “Link Card as 2nd Factor in AD”. Assuming the altSecurityIdentities permission is set (see the previous entry), the tool confirms the write. If the permission is missing, the tool warns you rather than silently failing.

Yes — this is the standard deployment pattern. With Active Directory storage the enrolment is written to the user object regardless of which workstation runs the tool, so one admin machine can enrol cards for the whole company. The command-line tools are documented at downloads.html#admin-cli and products.html#admin-cli; they are the same binaries you use for day-to-day operations. Licensees can request access and start testing straight away.

When a card is lifted from the reader, Windows fires a card-removal event and the credential provider stops looking for the card. DelayCardRemovalEventSec postpones that event by the configured number of seconds, giving a fast operator time to tap-and-lift while logon still completes. The default is a small value tuned for typical readers; setting it to 60 seconds is unusually long and usually points at something else being off (reader driver, cold-boot timing) — the setting is a mitigation, not a fix.

In a typical hardened setup the Microsoft Password Provider is hidden via the built-in CodeB Credential Provider Filter, not disabled outright. Disabling the Microsoft Password Provider system-wide can have unwanted side effects on Windows internals; hiding it via the filter cleanly removes the tile from the LogonUI without touching anything underneath. The same filter stops other providers from advertising themselves to LogonUI.

Yes — and uniquely so. The Credential Provider V2 is written in 100 % managed .NET code, which means it routes its cryptography through the Windows CNG layer. When you turn on the Group Policy setting “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”, Windows itself enforces FIPS 140-2 against every crypto call the credential provider makes.

Every other Windows credential provider we are aware of is built in native code with its own crypto path, which cannot be enforced via that policy. If you operate in a FIPS-mandated environment, CodeB lets you tick one GPO box and have the operating system guarantee compliance — no signed letters of attestation required.

Yes — CodeB products are designed and shipped with Regulation (EU) 2024/2847 in mind. The CRA was published in the EU Official Journal on 20 November 2024 and entered into force on 10 December 2024. The Article 14 reporting duties for actively exploited vulnerabilities apply from 11 September 2026, and the full manufacturer obligations apply from 11 December 2027. CodeB's Credential Provider V2 is an identity-management product and likely falls under Annex III important products with digital elements; CodeB Conference, CodeB Web SSO and CodeB Single Sign-On are in scope as PDEs as well.

What you get from us today, ahead of the application date:

• A documented product support period for security and vulnerability handling.
• Signed installers (Authenticode) for all current binaries, with cryptographic verification on rollout.
• A Software Bill of Materials (SBOM) in CycloneDX format available on request to licensees.
• A coordinated vulnerability disclosure contact for researchers and customers.
• Secure-by-default shipping configurations — no demo passwords, no anonymous endpoints, no opt-out telemetry.
• Update channels delivered free of charge for security fixes during the support period.

We position ourselves as CRA-ready rather than “CRA-certified” or “CRA-compliant” because the harmonised standards underpinning formal conformity assessment and CE marking against the CRA have not yet been published in their final form, and the regulation's application date is still in the future. The moment those standards land we will move to formal conformity assessment for the products in scope.

Yes. Licensees can request a current CycloneDX SBOM for Credential Provider V2, Web SSO, Desktop Switcher, Conference and Single Sign-On. Email us via the contact page; we send the SBOM by reply, signed.

We operate a coordinated vulnerability disclosure process. Security researchers and customers can report findings via our contact channel; we acknowledge receipt, work with the reporter on a timeline, and ship a fix as a signed update during the product's support period at no charge. The CRA's 24-hour / 72-hour / 14-day ENISA reporting windows for actively exploited vulnerabilities and severe incidents apply from 11 September 2026 onwards; our process is already structured to meet them.

Two options: a perpetual licence at € 49.99 one-time per licence, or an annual subscription at € 19.99 per licence per year. Perpetual licences can optionally add maintenance at 20 % of the purchase price per year, which covers version updates and continued support. Licences are counted by the higher of users vs. machines. Volume discounts and project pricing on request — see the pricing page.

Email support is included with every CodeB licence — perpetual or annual subscription, large customer or single seat — for as long as you use the product. No warranty cliff, no premium support tier, no per-incident fees. The optional maintenance contract on perpetual licences (20 % of purchase price per year) covers version updates, not support. Both licence types can be upgraded with a named engineer on your rollout calls — quoted separately as professional services.

Yes — every feature is enabled on every licence, so a small pilot purchase exercises exactly the same software a production rollout would. We typically advise customers to start with a small batch of annual-subscription licences for the pilot, then move to perpetual or an expanded subscription once the architecture is validated.