Identity & root of trust

Give every device an identity. Hold the CA that issues it.

Skans stands up one certificate authority per enclave and issues a real X.509 identity to every device on it — cameras, controllers, switches, servers and endpoints. The CA, the signing key and the identities live on the appliance and never leave the wire. Per-vendor drivers reach the cameras and controllers that can't enrol themselves — and re-read the certificate on the wire to prove it's serving before they call the job done.

Skans console · Devices
The Skans device inventory — cameras, switches and firewalls with certificate status, capability tier and enrolment lane.

One authority

One CA per enclave — and the keys stay yours.

Skans stands up a single certificate authority for the enclave: one chain to trust, one place identity is minted, one root every device certificate traces back to. It runs on your appliance, not someone else's server — your CA, your signing key, your identities. Nothing about your enclave lives in a vendor cloud.

  • One root, one chain — a single AD CS-backed authority (Skans Root CA) issues and anchors every device leaf, with one CRL and one trust decision to reason about.
  • Hardware-protected signing key — where a TPM is present the CA key is sealed in the Microsoft Platform Crypto Provider, non-exportable; a FIPS-140-3 HSM is a supported configuration override. The appliance runs FIPS approved-mode, which is not the same as CMVP-validated.
  • The appliance backs itself up — the directory system-state the CA lives in (NTDS.dit, GPOs, SYSVOL) and the control-plane database ship AES-256-encrypted off the source machine daily, so the box is rebuildable from media. Restore is a documented break-glass procedure, and full off-box escrow of the CA signing key is a partly-proven recovery path rather than one-click DR.
  • Air-gapped by default — keys and identities never leave; the one optional egress, the Skans Update Service, only pulls signed content down and never sends your data out.
Skans console · Backup
Backup and restore view — directory system-state and database backups shipped encrypted off the source machine, with disaster-recovery status.

Every device it can reach

Identity reaches every device — four lanes, chosen automatically.

How a device gets its certificate depends only on what the device can do. Skans routes each one to the right lane and picks automatically — the operator just presses Secure. Where a device genuinely can't take a certificate, Skans says so plainly instead of faking it, and secures the conduit around it.

  • Windows domain members — auto-enroll and auto-trust through AD CS and GPO, with zero operator steps. Shipped and proven end to end.
  • SCEP devices — self-enroll through the native NDES role with a dynamic one-time challenge; no shared secret to leak. Shipped and hardware-validated.
  • Cameras, intercoms & IoT that can't enrol — a per-vendor driver reaches the device's native API, issues a leaf, pushes and binds it, then re-reads the served certificate to confirm the serial matches. Proven on real hardware across leading camera and intercom brands — Axis, Hanwha, Bosch, 2N — plus generic ONVIF, Redfish and UniFi, inside a 100+-vendor library authored from each vendor's API and extensible to any vendor.
  • Industrial devices — OPC UA (GDS Push) and BACnet/SC get identity through their own protocols, signed by the Skans root rather than an external PKI. Business-edition depth.
Skans console · Devices
Device inventory showing each device's certificate status, capability tier and enrolment lane.

Why it matters

A cryptographic identity changes what everything else can do.

Issue a real certificate to a device and it stops being a guess. Identity becomes the anchor for correlation, admission, compliance — and independence.

The strongest anchor

A certificate is spoof-resistant, so it becomes the one stable key a device is known by. IP, MAC, hostname and VLAN all change — identity anchored on the cert survives the churn that quietly splits or merges attribute-keyed tools.

Admission you can trust

Cert-bearing devices are the ones 802.1X EAP-TLS lets onto the wire; anything without a Skans-issued certificate that chains to your root is rejected at the port. Identity first is what makes real network access control possible instead of a MAC allow-list (AC-3 / IA-3).

Evidence already in place

One CA issuing hardware-backed identity supports the NIST 800-171 / CMMC Identification & Authentication and System & Communications Protection controls — IA-5, SC-12, SC-13, SC-17 — as alignment an assessor can read, not badge-spam. Skans supports these controls; it never certifies you.

You own the keys

The authority, the signing key and every identity stay inside the enclave. Nothing of yours leaves the wire, and a severed WAN changes nothing about your protection.

People, not just devices

Operators sign in with hardware, not a password.

The same CA that identifies devices issues operator identities too. An admin binds a PIV hardware token to their directory account and signs in to the console with the card plus a PIN — strong, phishing-resistant MFA, proven today on Windows from the physical console session.

  • Bound by the CA, not the card's claim — login resolves the certificate's issuer + serial against a strong AD mapping first, so a card can't sign in as someone it wasn't issued to.
  • The token's management key lives in the vault — held under a hardware-protected (TPM-sealed) wrapping key, never by the operator, and every reveal is audited.
  • Driver-free FIDO2 / WebAuthn — designed and built, reusing the same resolver; not yet hardware-tested, so treat it as available-soon rather than shipped.
  • Honest FIPS posture — the token's FIPS level is vendor-stated pending CMVP; Skans runs in FIPS approved-mode and shows a visible gap banner instead of claiming validation.
Skans console · Passwords
The credential vault — device and service secrets encrypted under a TPM-protected key, with reveal and copy audited.

Runs itself

Identity that renews, revokes, and holds together on its own.

Once identity is issued, Skans keeps it healthy without operator work. Certificates renew before they expire, revocation is published, and a device stays the same entity across every change to its address or its hardware.

  • Self-healing PKI — a daily health service renews appliance certificates, republishes the CRL, and rebinds NPS after a DC-certificate renewal so EAP-TLS admission keeps working.
  • Renewal by lane — domain members auto-renew through GPO; SCEP devices renew via SCEP; driver-enrolled devices are tracked with expiry and re-pushed.
  • Revoke and supersede — decommissioning a device revokes its certificate first, and re-enrolling supersedes the old serial — all CRL-based, republished on a schedule.
  • Survives the churn — swap a NIC, move Wi-Fi to wired, take a new DHCP lease or rotate the certificate, and it stays one device: the cert anchor and its lineage keep identity stable.
Skans console · NOC
The NOC wall — fleet health, certificates, RADIUS/NPS serving and other live tiles across the enclave.

Talk to us

See Skans on your network.

Built for the teams running networks the cloud can't reach. Email us for a technical walkthrough — architecture, controls, and exactly how it stays offline.