Skip to content

Solution Architecture

This page shows every component of the Crayonic solution on one map, and then the deployment options you can pick from — from "just badges and Microsoft Entra ID" up to full fleet management and secure audio transcription into your EHR. Each option is a superset of the previous one; you can start small and add planes later without replacing anything.

1. The components

flowchart TB
  subgraph WALLETS["Wallets — what the user carries"]
    BADGE["Crayonic Badge™<br/>FIDO2 · PIV smart card · NFC · BLE<br/>e-paper display · fingerprint · microphone"]
    KV["Crayonic KeyVault™<br/>FIDO2 · PIV · Bluetooth key"]
    MIW["Crayonic Mobile ID Wallet<br/>FIDO2-certified phone wallet:<br/>passkeys · certificates · badge companion"]
    BIO["Crayonic BioCard<br/>biometric smart card"]
  end

  subgraph ENDPOINT["End-point tools — on the workstation"]
    BRIDGE["Crayonic Bridge<br/>USB dongle: BLE ↔ USB,<br/>proximity login / auto-lock"]
    AGENT["Crayonic Agent<br/>Windows service: device events,<br/>firmware updates, local CCM helper"]
    CP["Crayonic Credential Provider<br/>Windows logon with badge/passkey"]
  end

  subgraph MGMT["Management & integration — your data centre or cloud"]
    CCM["Crayonic Credential Manager (CCM)<br/>passkey & certificate lifecycle,<br/>self-service enrollment"]
    CDM["Crayonic Device Manager (CDM)<br/>fleet inventory, firmware, policies,<br/>telemetry, bridges"]
    CSA["Crayonic Secure Audio Service<br/>encrypted recordings, transcription,<br/>HL7 to EHR"]
    RTLS["Crayonic RTLS (beta)<br/>indoor location of badges,<br/>panic-button response"]
    COMMS["Crayonic Comms (beta)<br/>messages, calendar notifications,<br/>secure paging to the badge display"]
  end

  subgraph IOT["BLE coverage — mesh of Bridges, extended by IoT infrastructure"]
    MESH["Crayonic Bridges (BLE mesh)<br/>+ Wi-Fi APs with BLE gateway"]
  end

  subgraph EXT["Your systems"]
    ENTRA["Microsoft Entra ID<br/>(or AD / Google Workspace)"]
    EHR["EHR / EMR"]
    STT["Speech-to-text / LLM<br/>(e.g. Praxy Santé, local Whisper)"]
    CAL["Mail / calendar · nurse call · alarms"]
  end

  BADGE & KV & MIW -. "FIDO2 / PIV over USB, NFC, BLE" .-> BRIDGE
  BRIDGE --> CP
  BADGE -. "BLE beacons / paging" .-> MESH
  MESH --> RTLS
  MESH <--> COMMS
  COMMS <--> CAL
  BADGE & KV -->|USB| AGENT
  AGENT --> CDM
  AGENT -. "local helper on :17620" .-> CCM
  CCM --> ENTRA
  CDM --> ENTRA
  CP --> ENTRA
  MIW -. "BLE" .-> BADGE
  MIW --> CSA
  CSA --> STT
  CSA --> EHR
Component One-line role Runs on
Crayonic Badge / KeyVault The user's hardware credential: a certified FIDO2 security key and PIV smart card. The Badge adds a display, fingerprint sensor and microphone. Worn / carried
Crayonic Mobile ID Wallet A wallet in its own right: FIDO2-certified phone authenticator that carries passkeys and certificates and presents them to an endpoint over BLE through a Crayonic Bridge, exactly like a badge. Also the badge's companion app (badge management over BLE) and, in Option 4b, the encrypted-audio courier. User's phone (Android)
Crayonic Bridge USB dongle that makes a nearby badge look USB-connected — no pairing, no drivers. Its RSSI thresholds give hands-free login and auto-lock. Each shared workstation
Crayonic Agent Windows service reporting device/session events to CDM, applying firmware updates and policies, and acting as the local helper CCM needs to write FIDO2 credentials to a badge from the browser. Managed Windows endpoints
Crayonic Credential Provider Windows logon tile: sign in with the badge (FIDO2 to Entra or AD, or PIV). Windows endpoints
CCM Web admin + self-service for passkeys and certificates on badges; provisions FIDO2 methods into Entra ID through Microsoft Graph. Docker (your DC or cloud), or as an appliance with CDM
CDM Fleet management plane for badges, KeyVaults and bridges: inventory, firmware, policies, telemetry, audit; multi-tenant. Docker (on-prem or cloud)
Crayonic Secure Audio Service Stores end-to-end-encrypted badge recordings, lets the clinician decrypt in the browser with the badge, transcribes via your STT, and pushes results to the EHR over HL7. Docker (your DC or cloud)
Crayonic RTLS (beta) Real-time indoor location of badges from their BLE beacons — where is this person, and who is nearest — used above all to respond to a panic button pressed on the badge. Docker (your DC or cloud) + BLE coverage
Crayonic Comms (beta) Messages, calendar notifications and secure paging delivered to the badge's e-paper display over BLE, with acknowledgement back; integrates with mail/calendar, nurse-call and alarm systems. Docker (your DC or cloud) + BLE coverage
BLE coverage Both beta services listen to and reach badges through a BLE mesh formed by the Crayonic Bridges already on workstations. Where bridges are sparse (corridors, wards, open areas) coverage is extended with IoT infrastructure: Wi-Fi access points with a BLE gateway, either existing or deployed for the purpose. Facility

2. Deployment options

Option 1 — Entra ID only

The badge is a certified FIDO2 security key. Register it in Microsoft Entra ID as a passwordless method and it works everywhere Entra does — Windows sign-in, Microsoft 365, any Entra-federated app — with no Crayonic server.

flowchart LR
  U["User + Crayonic Badge / KeyVault"]
  WIN["Windows PC<br/>(Credential Provider optional)"]
  ENTRA["Microsoft Entra ID"]
  APPS["Microsoft 365 · federated apps"]
  U -->|"USB / NFC / BLE"| WIN
  WIN -->|"FIDO2 passwordless"| ENTRA
  ENTRA --> APPS
You deploy Nothing server-side. Optionally the Credential Provider MSI for a richer Windows logon; optionally a Bridge per workstation for proximity login/lock.
Enrollment User registers the key themselves in the Entra security-info portal (standard Microsoft flow).
You get Phishing-resistant passwordless sign-in.
You don't get Central visibility of which badge belongs to whom, remote revocation of a lost badge beyond Entra's own controls, firmware/policy management, PIV certificate lifecycle.
Good for Pilots, small teams, organisations already standardised on Entra passwordless.

Option 2 — Entra ID + CCM (credential lifecycle)

Add Crayonic Credential Manager when you need helpdesk-driven or self-service enrollment with approval, certificate (PIV) issuance, and an audit trail of which credential is on which badge. CCM writes FIDO2 methods into Entra on the user's behalf via Microsoft Graph; the Crayonic Agent on the endpoint is the local helper that lets the browser talk to the badge.

flowchart LR
  subgraph EP["Endpoint"]
    BADGE["Badge"]
    AGENT["Crayonic Agent<br/>(local helper)"]
    BROWSER["Browser: CCM self-service / admin"]
    BADGE --- AGENT
    AGENT --- BROWSER
  end
  subgraph DC["Your data centre / cloud"]
    CCM["CCM<br/>SPA + backend + Postgres + Redis"]
  end
  ENTRA["Microsoft Entra ID<br/>(Graph API)"]
  BROWSER --> CCM
  CCM -->|"fido2Methods, users"| ENTRA
  BADGE -.->|"FIDO2 sign-in"| ENTRA
You deploy CCM (Docker Compose: SPA, .NET backend, PostgreSQL, Redis, TLS proxy); Crayonic Agent MSI on endpoints where enrollment happens; an Entra app registration with Graph permissions.
Air-gapped / regulated variant Entra-isolation mode: CCM holds no Graph credentials and has no network path to Graph; a separate Entra Bridge tool carries signed bundles from a connected admin workstation. Same product, a deployment mode switch.
You get Everything in Option 1, plus approval workflows, helpdesk enrollment, PIV/certificate management, revocation and audit per credential.
Good for Organisations with a helpdesk, compliance requirements on credential issuance, or PIV/smart-card logon.

Option 3 — Entra ID + CCM + CDM (full fleet management)

Add Crayonic Device Manager when you operate a fleet: hundreds of badges, KeyVaults and bridges across sites. CDM gives inventory, firmware roll-outs, policy propagation (RSSI thresholds, lock behaviour), battery and session telemetry, and multi-tenant administration. The same Crayonic Agent that serves CCM reports to CDM.

flowchart LR
  subgraph EP["Endpoints"]
    BADGE["Badges · KeyVaults"]
    BRIDGE["Bridges"]
    AGENT["Crayonic Agent"]
    BADGE --- BRIDGE
    BRIDGE --- AGENT
    BADGE --- AGENT
  end
  subgraph DC["Your data centre / cloud — or one appliance"]
    CCM["CCM"]
    CDM["CDM<br/>backend + console + Postgres + MQTT"]
  end
  ENTRA["Microsoft Entra ID"]
  AGENT -->|"REST + MQTT: events, telemetry"| CDM
  CDM -->|"firmware, policies, commands"| AGENT
  AGENT -.->|"local helper"| CCM
  CCM --> ENTRA
  CDM -->|"admin sign-in"| ENTRA
You deploy Option 2 plus CDM (Docker Compose: backend, console, PostgreSQL, Mosquitto MQTT, workers). CCM + CDM are also available together as a single virtual appliance (OVA) for isolated networks, where the only permitted internet destination is Entra sign-in.
You get Everything in Option 2, plus fleet inventory, remote firmware updates, policy management for badges and bridges, telemetry, per-organisation tenancy and audit.
Good for Hospitals, factories, campuses — many shared workstations, many devices, several sites.

Option 4 — Secure audio: badge recordings transcribed into the EHR

Any of the options above can add the Crayonic Secure Audio Service. The badge records (a clinical consultation, a dictated note), encrypts on-device with keys derived from the badge's own FIDO2 credential, and the recording reaches the service as ciphertext only. The clinician later opens it in the browser, using the badge as their security key to decrypt, triggers transcription through your chosen speech-to-text provider, and sends the result to the EHR as an HL7 message. The service never holds a key that can decrypt a recording.

flowchart LR
  P["Plaintext audio<br/>badge only"] -->|"encrypt on badge"| C["Ciphertext<br/>transport + storage"]
  C -->|"badge as security key, in browser"| D["Decrypted in the<br/>clinician's browser"]
  D -->|"clinician action"| T["Transcript"]
  T -->|"HL7"| E["EHR"]
  classDef plain fill:#ffe0e0,stroke:#c00;
  classDef cipher fill:#e0f0ff,stroke:#06c;
  class P,D,T plain;
  class C cipher;

There are two ways to get the recording from the badge to the service. They can coexist on the same service; choose per site.

Option 4a — with Crayonic Bridge and Agent (managed workstations)

The Bridge dongle streams recordings off the badge, the Crayonic Agent on the workstation uploads them and verifies the service's signed receipt before the badge copy is deleted. Fits sites that already run Option 3.

flowchart LR
  BADGE["Badge<br/>records + encrypts"]
  BRIDGE["Crayonic Bridge"]
  AGENT["Crayonic Agent<br/>upload + receipt check"]
  CSA["Crayonic Secure Audio Service"]
  WEB["Clinician browser<br/>decrypt with badge"]
  STT["Your STT / LLM"]
  EHR["EHR (HL7)"]
  BADGE -->|"BLE"| BRIDGE -->|"USB"| AGENT -->|"HTTPS, resumable"| CSA
  CSA -->|"signed receipt"| AGENT
  WEB <--> CSA
  CSA --> STT
  CSA --> EHR

Option 4b — with the Crayonic Mobile ID Wallet as courier (no Bridge, no Agent)

The user's own Android phone, already paired to their badge, notices when the badge advertises "audio waiting", pulls the encrypted recording over Bluetooth, uploads it, and hands the service's signed receipt back to the badge so it can free the space. The phone proves it belongs to the badge owner with the badge's existing FIDO2 credential — no admin enrollment step — and holds only an upload-only token: a lost phone cannot read, decrypt or delete anything. No workstation, dongle or agent is needed at the capture site.

flowchart LR
  BADGE["Badge<br/>records + encrypts<br/>advertises 'audio waiting'"]
  PHONE["Mobile ID Wallet<br/>upload-only courier"]
  CSA["Crayonic Secure Audio Service"]
  WEB["Clinician browser<br/>decrypt with badge"]
  STT["Your STT / LLM"]
  EHR["EHR (HL7)"]
  BADGE -->|"BLE, dedicated link"| PHONE -->|"HTTPS, resumable"| CSA
  CSA -->|"signed receipt"| PHONE -->|"receipt → badge deletes"| BADGE
  WEB <--> CSA
  CSA --> STT
  CSA --> EHR
Option 4a — Bridge + Agent Option 4b — phone courier
Capture-site footprint Windows PC + Bridge dongle None beyond the user's phone
Uploader identity Device token issued by an administrator The badge's own FIDO2 credential, paired once by the user
Who can decrypt Only the clinician's browser with the badge Same
Deletion on the badge Agent verifies the service receipt Badge itself verifies the receipt
Availability Whenever the badge is at a managed workstation Whenever the user's phone is nearby with Bluetooth on
Platform Windows Android today

Speech-to-text and EHR are yours to choose. The service ships with a local Whisper engine and an adapter for Praxy Santé's medical transcription API; any STT with an HTTP API can be added through one adapter interface. Transcripts go to the EHR as HL7 v2 ORU^R01 messages over MLLP; the target system and sending/receiving identifiers are configured in the service.

Option 5 — Location and messaging: RTLS and Comms (beta)

Two further services turn the badge from a credential into a presence and communication device. Both are in beta testing and both ride on the same BLE coverage:

  • Crayonic RTLS locates badges indoors from their BLE beacons. The headline use is the badge's panic button: one press, and security sees on a floor plan where the badge is and who is nearest. It also answers "where is Dr. X right now" and feeds occupancy and workflow analytics.
  • Crayonic Comms delivers messages, calendar notifications and secure paging to the badge's e-paper display, with delivery/acknowledgement back to the sender. Typical sources: mail/calendar, nurse-call, lab-result and alarm systems.
flowchart LR
  subgraph FACILITY["Facility"]
    BADGE["Badges<br/>beacons · panic button ·<br/>display for paging"]
    BR["Crayonic Bridges<br/>on workstations<br/>(BLE mesh)"]
    AP["Wi-Fi APs with BLE gateway<br/>(IoT infrastructure, where<br/>bridges are sparse)"]
    BADGE -. "BLE" .-> BR
    BADGE -. "BLE" .-> AP
  end
  subgraph DC["Your data centre / cloud"]
    RTLS["Crayonic RTLS<br/>positioning · floor plans · alerts"]
    COMMS["Crayonic Comms<br/>messaging · paging · calendar"]
    CDM["CDM<br/>(fleet, bridges, policies)"]
  end
  EXT["Security desk · nurse call ·<br/>mail/calendar · alarms"]
  BR --> RTLS
  AP --> RTLS
  BR <--> COMMS
  AP <--> COMMS
  RTLS --> EXT
  COMMS <--> EXT
  CDM -.-> BR
You deploy RTLS and/or Comms services (Docker, alongside CDM). BLE coverage is the prerequisite: the Bridges already on workstations form a BLE mesh; where that is not dense enough for the areas you care about, add Wi-Fi access points with a BLE gateway (existing enterprise APs with BLE radios can often be used) or dedicated gateways. A site survey sizes this.
Depends on CDM (Option 3) for bridge and badge inventory; badges with the panic button / display features.
You get Panic-button response with location, staff/asset location, secure paging and notifications to the badge without a phone.
Status Beta — deployed with selected customers; contact Crayonic for a pilot.

3. Choosing

Need Option
Passwordless sign-in, minimal infrastructure 1
Helpdesk / self-service enrollment, PIV certificates, per-credential audit 2
Fleet of devices, firmware and policy management, multi-site 3
Clinical dictation / consultation recording into the EHR, managed workstations already in place 3 + 4a
Same, but capture happens where there is no managed PC (wards, home visits, small practices) any + 4b
Isolated / air-gapped network 2 or 3 in Entra-isolation mode, CCM+CDM appliance
Panic button with location, staff/asset location 3 + 5 (RTLS), plus BLE coverage
Secure paging, notifications to the badge without a phone 3 + 5 (Comms), plus BLE coverage
Phone-based passkeys/certificates instead of, or alongside, a badge Mobile ID Wallet in any option; presented to endpoints via a Bridge

4. Where things run — summary

Component User device Endpoint Your DC / cloud Microsoft cloud
Badge / KeyVault / BioCard ●
Mobile ID Wallet ●
Bridge, Agent, Credential Provider ●
Wi-Fi APs with BLE gateway (RTLS/Comms coverage) ● (facility)
CCM, CDM, Secure Audio Service ●
RTLS, Comms (beta) ●
Entra ID (sign-in, FIDO2 methods) ●

All Crayonic server components are delivered as Docker images (or one OVA appliance for CCM + CDM) and store their data in PostgreSQL plus, for audio, an S3-compatible object store. Nothing Crayonic-hosted is required for any option.

5. Further reading