Mobile Credentials

Two routes put the same pass on the same phone.

View the deck →  ·  Download the PDF →

Knight Watch builds mobile credentials two ways, and they are at two different stages. This page says which is which.

A mobile credential does three things: it turns an identity into a pass, it puts that pass in a phone, and it lets a reader at a door honour it. The difference between one route and another is not the idea — it is who mints the pass, where it lands on the phone, and what happens the moment somebody should no longer have it.

Open the deck · Download the PDF

The two routes

	Route one — HID Mobile Access	Route two — KnightPass
Where it lives	Security Expert Plus, Knight Watch's platform layer for Schneider Electric EcoStruxure Security Expert	KnightPass, Knight Watch's own mobile credential platform
Who mints the pass	HID Origo, in your own cloud tenant	The WaveLynx Wallet platform
Where the pass lands	The HID Mobile Access app	Apple Wallet or Google Wallet
How the holder receives it	HID emails a 16-character alphanumeric invitation code	A provisioning link — shown as a QR code, or sent by email or text
Where it deploys	On-premises, Windows Server / IIS with your own SQL Server database	Hosted by Knight Watch on its own AWS account
Status	Built and hand-validated against HID's CERT (pre-production) tier. Ships disabled by default. Not deployed in a production tenant. Available as a per-deployment integration, enabled once your own HID Origo tenant is configured.	Running in production today on Knight Watch's own AWS account. Verified 31 August 2026.

Route one — HID Mobile Access, via the HID Origo API

Visitor mobile credentials via HID Origo are built into Security Expert Plus, Knight Watch's platform layer for Schneider Electric EcoStruxure Security Expert.

1. Check in. Security Expert Plus creates the visitor's HID Origo user and issues an HID Mobile Access credential in one combined call to the HID Mobile Access API 2.2. An OAuth2 client-credentials token is cached for the lifetime HID returns and refreshed 60 seconds early, serialised behind a lock so a burst of concurrent check-ins triggers one token call rather than many.
2. Invite. HID Origo issues a 16-character alphanumeric invitation code and HID emails it directly to the visitor. The operator's check-in screen displays only the credential identifier — the invitation code is never shown in the operator UI.
3. Redeem. The visitor redeems the code in the HID Mobile Access app, per HID's Mobile Access API 2.2 documentation. There is nothing to install from Knight Watch.
4. Check out. Check-out revokes the credential and deletes the Origo user, so it cannot open a door after the visitor leaves. Revocation is idempotent — an already-removed credential is treated as success — and a revoke failure never blocks the visitor's check-out.
5. Sweep. A background job, on a default schedule of a check every 15 minutes, revokes the credential of any visitor still on site past their scheduled departure and deletes the Origo user. The job is not scheduled at all unless HID Origo is configured and enabled.

A returning visitor whose Origo user still exists returns 409 Conflict on issue. The integration resolves the existing Origo user by email via SCIM search and issues to that user instead of failing the check-in. The email address is validated for length, form, quotes, backslashes and control characters before it reaches the SCIM filter, and a rejected address surfaces the original 409.

Employee (cardholder) credentials can be issued and revoked by an operator from the user profile. The schema holds one active credential per cardholder — a filtered unique index on the Security Expert user id where the revoked-at timestamp is null — and revoked credentials are retained rather than deleted, stamped with the revoke time and the operator who performed it, so the record stays auditable. This is implemented on a feature branch and is not yet merged to the mainline.

Check-in and check-out are designed not to block on the integration: if issuing or revoking a mobile credential fails, the error is logged and the visit record still completes, with a locally assigned visitor badge number recorded for identification. That badge number is a visitor-management identifier, not an access-control credential — it does not by itself grant door access.

The issued card number is not written into Schneider Electric EcoStruxure Security Expert, so the credential alone will not grant at a door until a matching cardholder record exists there. Writing it automatically is deliberately not built: the draft implementation was removed in pre-merge review because it wrote directly against the vendor-owned Security Expert database. Re-enabling door registration needs SOAP user-provisioning verbs on the Security Expert client plus the site's record group, facility code and access-level ids.

Route two — KnightPass, on the WaveLynx Wallet API

KnightPass provisions mobile access credentials into Apple Wallet and Google Wallet through the WaveLynx Wallet API. Four credential-issuance workflows are live today:

• Direct device provisioning — one of the two underlying paths; the credential is provisioned directly to the device.
• A wallet provisioning link — displayed as a QR code, or copied and sent by email or text. The holder opens it on their phone and adds the pass. KnightPass itself has no end-user app to install.
• A visitor pass with an active window — its lifetime set at the moment of issue, in days, hours and minutes, from a five-minute minimum up to thirty days. The pass is provisioned as an ephemeral guest credential and the WaveLynx Wallet platform stops honouring it when the time is up. Nobody has to remember to switch it off.
• Bulk issuance from a CSV — uploaded or pasted, with per-row results and a downloadable success/failure report.

Underneath there are two paths, not four: direct device provisioning, and WaveLynx corporate weblinks. The visitor pass is a weblink with an expiry window attached, and bulk import issues a weblink per CSV row. Bulk is a sequential loop of individual calls rather than a batch API — a 500-row CSV is 500 round trips inside one request.

Onboarding is enforced in a fixed order rather than merely documented: the customer record, then wallet branding, then the WaveLynx group, then credentials. Wallet branding is the customer's two brand colours — a background colour and a text colour — not their logo; the wallet assets are generated from those two values. Samsung Wallet is deliberately not supported.

After issue: the half that matters

KnightPass listens to WaveLynx for the whole life of the credential. Only three statuses trigger a backend action — ACTIVE maps to Provision, SUSPENDED to Suspend, DELETED to Delete. The transitional statuses NOT_COMMISSIONED and PENDING deliberately trigger no backend sync, verified by unit tests that assert the adapter is never called. Every processed webhook is persisted in full — the parsed payload alongside its processing outcome — for audit and debugging.

A failed write into the customer's system retries five times, at 1, 5, 15, 60 and 240 minutes, then stops and stays marked failed. It does not retry forever and it does not quietly mark itself successful.

Every backend sits behind the same contract: one sync call carrying three actions — Provision, Suspend, Delete — to the customer's access control system, whether that is KnightKey, Lenel OnGuard, Security Expert, or a generic webhook. Adding a backend means writing one adapter, not per-customer code. Four adapters are compiled into the container running in production today and resolved per customer at runtime. The generic webhook adapter — provision, suspend and delete POSTed as a fixed JSON payload to a customer-supplied URL with an optional API key in an x-api-key header — is the integration path available today. The vendor-specific adapters for KnightKey, Schneider Electric EcoStruxure Security Expert and Lenel OnGuard are written and deployed but have not yet been validated against a live panel.

On the HID route the equivalent work is in development: status callbacks from HID Origo land on a dedicated receiver authenticated by an unguessable, rotatable secret in the callback URL — compared in constant time, answered with an opaque 404 on mismatch, and never echoed back in any API response or log. The handler is idempotent and only ever advances the status of a credential already issued, so it cannot be used to create or alter access. HID Origo delivers these events as CloudEvents webhooks over TLS; we authenticate every delivery ourselves rather than trusting the source address. That receiver is on a feature branch and is not in any released build.

Control and audit

Operators sign in to KnightPass with Microsoft Entra ID single sign-on, single tenant. Administrative surfaces re-check the admin role against the database and return 403 rather than merely hiding a menu.

Credential and customer lifecycle actions write an immutable audit row — issue, visitor issue, suspend, delete, card update, bulk issue, and customer create, update, delete and group provisioning. Each row carries the acting user's Entra object id and email, the action, the target type and id, and a UTC timestamp, reviewable in-app by administrators. Admin role changes, allow-list changes and integration-configuration updates are not yet in the ledger; that coverage is on the roadmap.

The audit trail is a credential-lifecycle record, not a door-event log. Reader taps stay in the access control platform, where they belong.

KnightPass data lives in PostgreSQL across seven tables with code-first migrations. KnightPass authenticates to WaveLynx by signing a challenge rather than storing a shared password: WaveLynx issues a nonce, KnightPass hashes it with SHA-256 and signs the hash with an ECDSA private key, then exchanges that signature for an auth token and a refresh token, repeating the exchange every five minutes. That P-256 private key is not in the repository — verified across the full commit history — and is never returned by any API: the admin-only configuration endpoint reports credentials as set/unset flags rather than values. The key is held in AWS Secrets Manager. The WaveLynx API key is currently stored in the application database rather than in Secrets Manager.

On the HID route, staffed lobby check-ins record the id of the operator who checked the visitor in, and credential issue and revoke are tied to check-in and check-out with timestamps, logged against the visitor and credential identifiers. Operator names are not recorded; self-service kiosk check-ins record no operator, and check-out records no operator.

Where it deploys, and who supports it

KnightPass is live at pass.knightwatch.net, where one container image serves both the React admin console and the .NET API from the same origin. It runs on AWS App Runner, auto-deploying from Amazon ECR, behind a CloudFront distribution that terminates the public hostname. Every push to main builds the client and the .NET API and runs the xUnit test suite, and only on success is an image built and pushed. Production rollout runs from that same pipeline. KnightPass ships as an internal Knight Watch administration tool: provisioning is performed by Knight Watch on the customer's behalf, and a customer self-service portal is not built.

Security Expert Plus deploys on-premises to Windows Server / IIS with your own SQL Server database, installed by our MSI, running inside your network. Mobile credentials on that route are issued through HID Mobile Access on the HID Origo cloud platform, in your own HID Origo tenant; the visitor's name and email are sent to HID Origo to issue the credential, and the application stores the local visitor record and a reference to it.

Business-hours support is standard, with an optional Premium tier adding 24x7 response for critical incidents. Final coverage, response targets and escalation are set by the executed support addendum. Knight Watch installs and services access control platforms as an integrator — Security Expert and Lenel OnGuard among them — so the team writing the integration knows the panel behind the door.

Honest status

KnightPass runs in production today on Knight Watch's own AWS account. Verified 31 August 2026: the health endpoint reported the service healthy with its database connected and its WaveLynx integration authenticated, and the deployed image matched the repository's current HEAD. A deployment at a named customer is not evidenced, so no customer reference, logo or case study appears on this page. Which WaveLynx environment the live service points at is per-deployment configuration the repository does not record, and the code default is staging — confirm the environment with us before planning a cutover. The vendor-specific adapters for KnightKey, Schneider Electric EcoStruxure Security Expert and Lenel OnGuard are written and deployed but have not been validated against a live panel; the generic webhook adapter is the integration path available today.

The HID Mobile Access integration is built, not deployed. It is implemented against the HID Mobile Access API 2.2, covered by 53 automated test cases across five dedicated test suites — with fixtures captured from live HID CERT traffic — and hand-validated against HID's CERT (pre-production) tenant during development in mid-2026. The HTTP client itself has no unit tests of its own. It lives on a single customer engagement's feature branch, is not merged to the mainline, ships turned off and unconfigured, and as of 23 August 2026 has not been enabled against a production HID Origo tenant. Enabling it is customer-side runtime configuration: your own HID Origo tenant, System Account credentials and a credential part number. It is available on request. No HID partnership, Technology Partner certification or production approval is claimed, because none is evidenced.

No numbers we cannot show the working for. There is no uptime percentage, no response-time target and no 24/7/365 commitment on this page, on either route.