Skip to content

Crayonic Device Manager (CDM)

CDM is the central management plane for Crayonic hardware fleets — Crayonic Badge, Crayonic KeyVault, and Crayonic Bridge. It gives security and IT administrators a single console to inventory devices, watch authentication and session activity in real time, push firmware, and prove compliance across many tenants.

CDM ships with a Windows service (the Crayonic Agent), a multi-tenant REST API, and a web console. It deploys on-premises or in any cloud — Azure, AWS, GCP, or a private Kubernetes cluster — and exposes a REST API for SIEM and Microsoft Sentinel / Security Copilot integrations.

At a glance

Fleet dashboard

The Dashboard opens on a fleet overview. Each tenant sees its own machine, bridge, and badge counts; firmware adoption; agent and bridge update policies at a glance; an authentication-activity heatmap; the live event feed; and the top users and badges by adoption.

What CDM is

CDM is a three-tier system:

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  Crayonic Agent │    │   REST API +    │    │   Web Console   │
│ (Windows svc)   │───▶│   Workers       │◀───│                 │
│ on every host   │    │ (Flask · Postgres) │  │                 │
└─────────────────┘    └─────────────────┘    └─────────────────┘
        │                       ▲
        └────── MQTT ───────────┘   (live events, commands, telemetry)
  • Crayonic Agent runs as a Windows service on every monitored workstation. It detects badge presence, drives FIDO2 / WebAuthn ceremonies, watches PIV smart cards and PKI certificates, captures workstation lock/unlock and session events, ships them over MQTT, and applies firmware/policy updates the backend pushes to it.
  • Backend is a Flask REST API backed by Postgres, an MQTT subscriber that ingests agent telemetry, and a worker fleet for firmware rollouts and command dispatch.
  • Web console authenticates against Microsoft Entra ID or Google Workspace and respects role-based isolation per organisation.

Feature highlights

Real-time fleet visibility

Machines list

  • Every Crayonic Agent reports back over MQTT the moment something changes: badge connect/disconnect, smart-card reader plug events, certificate detection, session lock/unlock, FIDO authentication start/success/fail, agent and bridge firmware versions, RSSI thresholds, and device-group membership.
  • The Machines list shows hostnames, NetBIOS names, domain, agent version, current connectivity (online / on-call / offline), assigned organisation and device group, and which bridge and badges are paired right now.
  • Each row deep-links to a per-machine detail page with a logon timeline, connected hardware, applied policies, and recent events.

Per-machine deep dive

Machine details

The machine page rolls up identity (NetBIOS / FQDN / agent version), the effective settings (org default → device group → machine override), every paired bridge and badge with firmware versions, the authentication-and-trust posture (verified factors, enrolment method, PoP results), and a live tail of the most recent events.

Badge and bridge inventory

Badges list

Badges and bridges are first-class resources. Each row tracks firmware version, hardware revision, last-seen timestamp, battery level, and the machine / badge group / case ID it's currently assigned to. Filterable, exportable, and bulk-assignable from the same screen.

Bridges list

The Bridges view exposes the FIDO and Smart-card bridge enable flags, RSSI connect / fast-connect / disconnect thresholds, hardware and bootloader versions — all sortable for fleet hygiene.

Live security event stream

Events stream

A unified event log captures everything the agent sees:

  • Authentication events — session create / lock / unlock / terminate, console logon / logoff, FIDO authentication started / succeeded / failed, smart-card insert / remove, certificate detection.
  • Device events — bridge connect / disconnect, badge connect / disconnect, firmware update applied, heartbeat.
  • System events — agent start / stop, configuration update, policy applied.

Filter by machine, badge, bridge, user, certificate, or time range. Export to CSV or stream to a SIEM via the REST API.

Multi-tenant organisation management

Organisations

CDM is multi-tenant by design. Organisations have:

  • Complete data isolation — users only see machines, badges, bridges, events, and audit logs scoped to their organisations.
  • Role-based access — system-level (superadmin, admin, user) and organisation-level (org_admin, org_user, org_viewer).
  • Inheritable settings — bridge defaults, badge defaults, agent and bridge firmware policies, and update windows defined at the organisation level cascade into device groups and individual machines, with overrides at any level.
  • Cross-org guards — a machine that belongs to multiple organisations is flagged in the UI; superadmins get a separate "Unassigned Machines" tray.

Firmware management

The agent, bridges, and badges are all firmware-managed from CDM. Each surface has its own policy:

  • Hold — never update.
  • Pinned — keep this exact version.
  • Latest — track the latest stable channel.
  • Pilot — opt a subset into a staged rollout.

Policies are layered (org → device group → machine override) so you can pilot a build on a single device group without affecting the rest of the fleet. Firmware rollout dashboards show progress, error rates, and stuck devices.

Automatic workstation locking

When a paired Crayonic Badge moves out of bridge range (configurable RSSI threshold), the agent locks the workstation. Configurable per-organisation, with optional grace periods.

Authentication & enrolment

  • Microsoft Entra ID and Google Workspace SSO for the console.
  • FIDO2 / WebAuthn passkey ceremonies driven by the Crayonic Agent and the connected badge.
  • Trusted-roots matrix and pending-enrolment queue for superadmins to gate device onboarding.
  • PIV / smart-card and PKI certificate discovery and tracking.