Release notes

This is the current-release summary for Skans 2.0 — the first shipping release of the appliance, so there is no prior version history to reconcile against. It states what the appliance actually does today, grouped by domain, and calls out anything still on the roadmap explicitly. Where a capability ships with an honest boundary, that boundary is named, not hidden.

Recent releases #

• 2026-07-17 — Agent v0.4.0: security hardening + verified self-update. An agent’s identity is now bound to its authenticated mTLS certificate — never to anything the client reports about itself — and signed command sets are bound to the specific target agent, so a command captured from one agent cannot be replayed to another. Self-update verifies every release (SHA-256 + Authenticode) before a staged swap with rollback, and v0.4.0 rolled out fleet-wide through that channel. Alongside it: driver packs 2026.7.16e (Cisco Catalyst 9200/9300/9500 switches + ASA firewalls) and the 2026.7.17 series (Cisco FTD full lanes — certificate renewal, API config snapshot, and driver-automated telemetry configuration — plus ASA monitor-push, IOS-XR, and Catalyst 9800 AP-LSC).
• 2026-07-16 — Alert Rules & Notifications. The /alerting console page: alert-rule management, suppressions with a recorded-justification guardrail on compliance-tagged rules, snooze with expiry, escalation / renotify, and per-channel notification delivery health. See Alerts & monitoring.

Platform & runtime — Shipped #

The flagship is a single self-contained Windows Server appliance (an open-source Linux SKU is the secondary flavor), sized for one site of up to ~5,000 devices (SRS PERF-01). Everything runs on the enclave — no runtime internet dependency.

• Runtime: .NET 10; an ASP.NET Core + Blazor console bound on :7328 (HTTPS).
• Stores: SQL Server / SQL Express holds control-plane state; OpenSearch holds telemetry, metrics, events, inventory, and vulnerabilities. Volume lives in OpenSearch, which is why the relational DB stays tiny.
• Run model: always-on, supervised Windows services — SkansControlPlane, SkansAgentHub, SkansCollector, SkansAgent — that start at boot and restart on failure, not scheduled scripts. Periodic jobs (backups, feed sync, drift checks) run in-process inside the control plane on internal timers; there is no separate scheduler service.
• Agent transport: mutual-TLS REST on :7326. The agent hub holds no signing key; the trusted core signs commands over a local pipe.

See Ports & endpoints for the full list.

Identity & CA — Shipped #

The appliance becomes the enclave’s root of trust. On the Windows SKU it stands up native AD DS (domain controller, DNS, Kerberos, GPO) and an AD CS Enterprise Root CA (“Skans Root CA”) that auto-publishes its root to Trusted Root and NTAuth and enables GPO auto-enrollment. The Linux SKU delivers the same outcome through step-ca, Samba, and FreeRADIUS behind a provider abstraction.

• Per-device X.509 identity issued from the built-in CA — no shared passwords.
• The CA private key is TPM-backed by default (Microsoft Platform Crypto Provider, non-exportable); an HSM / CNG-KSP is overridable.

See Device identity.

Network access control — Shipped #

802.1X EAP-TLS admission via NPS keeps unknown devices off the wire — proven end-to-end (Access-Accept, NPS Security event 6272). RADIUS-assigned VLANs segment camera/IoT gear.

See Network access control.

Two device lanes & the driver pack — Shipped #

Skans manages devices in two lanes, chosen automatically by device type:

• Agent-managed Windows endpoints — the Skans agent ships inventory, metrics, Defender health, WUA patching, and log shipping over mTLS. Windows event collection is the always-on agent lane.
• Agentless IoT / OT / network gear — the collector SNMP-polls and ingests syslog and traps. Rule: Windows is never SNMP-polled.

Vendor knowledge lives in the Skans Driver Pack — a signed, separately versioned artifact loaded at runtime, out-of-process in Skans.DriverHost, with hot-reload proven (no console restart).

See The driver pack and Enroll a device.

Patching & firmware — Shipped (Partial) #

The appliance pulls Microsoft Update itself via WUA (ServerSelection=2); the agent then installs to endpoints in rings, maintenance windows, and reboots — the endpoints never touch the internet. The WSUS role is deliberately not used (a confirmed dead-end on Server 2025).

• Firmware is flagged, not auto-patched. It can be pushed on demand and is SHA-256 re-verified over HTTPS before it lands.

See Patching.

Backup & DR — Shipped (restore is manual) #

The backup requirement is get data off the source. That ships:

• Directory — AD system-state IFM (NTDS.dit, GPOs, SYSVOL).
• Whole set shipped off-box — the full backup set leaves the appliance.
• Database — Tier-1 encrypted FULL + LOG on SQL Express (default 30-minute RPO, restore-tested); Tier-2 SQL Always On is an operator-provided scaffold.
• OpenSearch — scheduled filesystem-repository snapshots; restore proven in ~1–2 minutes.

See Backup.

Credential vault — Shipped #

Device and service credentials live only in an encrypted vault — never plaintext JSON. It uses envelope encryption: a per-secret AES-256-GCM data key wrapped by a TPM-held KEK (CNG Platform Crypto Provider, non-exportable), bound to additional authenticated data, with online KEK rotation, migration re-encrypt, and decrypt-auditing. This replaces DPAPI null-entropy storage. Device secrets stay reversibly encrypted because they must be replayed to the device.

See Manage credentials.

Monitoring — Shipped (Partial) #

Monitoring is push-first and correlated — collect-once / serve-many into a materialized device-state index, with findings bounded per device rather than a raw event firehose. The AlertEngine fires in seconds. Self-health watches the box’s own vitals every 15 minutes: C: disk, RAM, CPU, the SQL Express 10 GB cap, OpenSearch health, and core-service liveness.

See Alerts & monitoring.

Vulnerability management — Shipped (hand-off) #

A CVE + MITRE ATT&CK feed is matched against live inventory; each finding carries its fixed-in version and hands off to the agent’s patch-approval flow.

See Vulnerability management.

Compliance evidence — Shipped (enabler) #

Skans maps its technical controls to NIST 800-171 / CMMC Level 2, 800-53 Moderate/High, and CIS/STIG at mandated defaults, and generates assessment-ready evidence from live state.

See NIST 800-171 / CMMC evidence.

RBAC & login — Shipped (MFA partial) #

Access control is capability-based RBAC, AD-authoritative. Forms login is rate-limited (5/min/IP → 429) and audited, with a 15-minute idle lock and Sign-out. Optional OIDC federated console SSO (AD FS / Keycloak) is single-factor (amr=federated).

See Roles & RBAC and Smart-card login.

FIPS & cryptographic posture — Shipped (approved-mode) #

The appliance runs in FIPS approved-mode (Windows FIPS policy on; Schannel prefers TLS 1.3 with a 1.2 floor). The CA key is TPM-backed and non-exportable by default.

Preview / Roadmap #

Design-stage or in-flight — not something you can enable in this release:

Next #

• How Skans works → — the mental model behind these capabilities
• NIST 800-171 / CMMC evidence → — the compliance boundary in detail
• Ports & endpoints → — the full network reference
• Troubleshooting → — when something doesn’t line up