For technical buyers

NAC and 802.1X are the right idea, but they are hard to run well, and one mistake takes down a teller printer or a phone. Scanners miss what does not answer. Agents miss everything that cannot run one. And when the examiner asks what was on the network last quarter, the answer is a spreadsheet.

We are engineers first. We built it the way we would want a vendor to build something that sits on our own network: small, read-only, honest about what it cannot see, and able to prove what it says. This page says what it does, how, and what it does not do yet.

appliance start: Runs the appliance on this computer. The web interface listens on 127.0.0.1 only, unless you add -lan.
appliance appliance: Runs it as a server, over HTTPS on port 8443 by default.
appliance verify, report-verify: The offline verifiers the examiner runs.
appliance audit, rewind, segments, tripwires, metrics, reconcile, export: Read-only tools over the data folder, safe while the appliance runs.
appliance capture: Records what the appliance reads from one device, for support. Credentials are never written.
appliance dev: The real appliance against four simulated SNMP devices, for a demo or a trial.

How work flows

Collect. A read-only SNMP client polls each source, every 150 seconds by default.
Work out what changed. Engines with no network or disk access compare the new tables with the last.
Write once, with the record. One database transaction writes the new state, the alert queue and the audit entries together; a cycle that fails writes nothing.
Sign. A checkpoint of the whole log, signed with Ed25519 every 15 minutes when the log has grown and at every sign-off.
Tell people. Alerts go to destinations an Admin set up, each with its own filters.
Decide. A Reviewer signs each decision with an authenticator code entered in the last five minutes.
Prove. An evidence pack for any date range.

Storage is SQLite, built into the program in pure Go, in one data folder that only the appliance’s account can read.

Protocol: SNMP GET, GETNEXT and GETBULK on UDP 161. Nothing else touches your switches.
Version: SNMPv3 authPriv. SHA-256 and AES-128 by default; SHA-224, SHA-384 and SHA-512 accepted; SHA-1 accepted with a warning. MD5, DES, noAuthNoPriv, authNoPriv and SNMPv1 are refused, and nothing is sent with them. SNMPv2c only as an explicit, logged exception with a reason and an end date.
Tables: The system group; IF-MIB ports (with IEEE8023-LAG-MIB or ifStackTable for link aggregation); Q-BRIDGE-MIB or BRIDGE-MIB MAC tables; IP-MIB ARP and IPv6 neighbors; LLDP-MIB, plus CISCO-CDP-MIB on Cisco; ifLastChange and inbound octet counters for tripwires.
Cisco per-VLAN MAC tables: Handled. It reads the operational VTP VLANs, then the MAC table once per VLAN context.
Recognizing your gear: Each source is matched to a vendor profile by its sysObjectID and sysDescr, which picks how its MAC table is read; each poll records the profile used. Test connection names the maker of any SNMP device from the IANA enterprise registry, shipped in the program.
What you set up: A read-only SNMPv3 user, a view over the tables above, and the appliance’s address in the SNMP access list. Never a write view.
Polite to the network: One poll per source at a time; a 2-second timeout with 2 retries; each walk capped at 100,000 rows and 60 seconds; each poll at 500,000 values, 32 MiB and 1,024 VLAN contexts. Failed sign-ins are spaced so it never locks out your service account.
Does it work with my gear: Standard managed switches and firewalls that answer SNMPv3. Named models are being checked in our lab. Send us your models through the contact form.

Never writes to your network. The SNMP client offers only Get, GetNext, GetBulk, Walk and BulkWalk. Four tests fail the build if a Set method or a SetRequest appears.
Never blocks a device. When a port should be shut, the alert prints the command (Cisco syntax today) for a person to run.
Never contacts GigID Labs. No telemetry, license check or update check. Integrations refuse gigidlabs.com and ignore proxy settings from the environment.
Never sends your data to an AI service.
Never approves a device on its own. Imports, rules and suggestions never approve anything.
Installs no agents and needs no credentials on your computers.
Never scans on its own. Scan my network runs only when a person starts it, stays on the attached subnet, at 50 addresses a second by default (200 at most), with no TCP connections or port probes.

What it holds: Device identifiers (MAC, IP, host name, maker), where each was seen, alerts, the names and roles of the people who signed, and the audit log. No customer account or member data. Host names can contain a person’s name, so treat exports as internal data.
Where: One data folder on the computer it runs on. Nowhere else.
Secrets: Switch credentials, integration secrets and authenticator secrets are sealed with AES-256-GCM under data keys kept in files only the appliance’s account can read. Secrets print as [redacted] everywhere, and a final scrubber checks every page, log line and outbound payload.
Database at rest: Not encrypted by the appliance. Use full-disk encryption: BitLocker, LUKS or FileVault.
Retention: The audit log and checkpoints for the life of the log; per-poll detail for 30 days by default, each purge logged; hourly roll-ups for the life of the log; Rewind snapshots as a cache rebuilt from the log; the newest 500 delivery attempts per destination and kind.
What leaves, only when you set it up: SNMP reads to your sources; alerts and the audit stream to your destinations; an optional Microsoft Graph pull from your own tenant; files people download. Every destination is a log entry, and the Examiner role can see the list.
Backups: Not built yet; planned. Until then, copy the data folder while the appliance is stopped, and protect the copy like the appliance: it holds the keys.

Every entry is RFC 8785 canonical JSON, so anyone can re-hash it.
Each entry carries the SHA-256 of the one before it.
The log is a Merkle tree built the way Certificate Transparency builds one (RFC 6962, RFC 9162).
Checkpoints are C2SP signed notes, signed with Ed25519: every 15 minutes when the log grows, at every sign-off and before every Rewind answer.
The log is audited at every start, daily in full, at every pack export and on the examiner’s computer.
Packs have a fixed layout: an in-toto v1 manifest in a DSSE envelope, the checkpoint, the keys, the entries, inclusion and consistency proofs, and four readable files.
The offline verifier runs seven checks with distinct exit codes, and shares only three small packages with the appliance, so a bug in the store or the web layer cannot make a bad pack pass.
A by-hand procedure needs no GigID Labs software.
Anchors: the verifier compares history with a checkpoint held off the box (the previous pack, or your SIEM). A restore or rollback leaves a permanent discontinuity entry that every later pack prints.

What it does not prove yet: the evidence key is a software-protected file, not sealed in a TPM (planned). A pack with no anchor says “CHECKPOINTS NOT ANCHORED” rather than claiming more.

A user name, a password of at least 15 characters (hashed with Argon2id) and a 6-digit authenticator code. No password-only accounts.
Signed actions need an authenticator code entered in the last five minutes; each code works once.
Sessions end after 15 minutes idle or 8 hours in total. Failed sign-ins back off from 2 seconds to 15 minutes.
Five roles: Viewer, Reviewer, Admin, Examiner (read-only, with an end date, plus exports) and Break-glass. One permission table drives every route and write, and each write checks the role again inside its own transaction.
Separation of duties shows in the data: every signed entry carries the person, how they signed in and their roles. One person holding Admin and Reviewer prints “single-operator mode” on every sign-off and pack.
Browser protections: a strict Content-Security-Policy, CSRF protection, SameSite=Strict cookies, a Host allowlist, TLS 1.3 minimum, and no scripts from a CDN.
Not yet: single sign-on through an identity provider is planned.

Release builds are reproducible: every platform is built twice from fresh clones and must match byte for byte, or the release fails.
A release carries seven binaries, a CycloneDX SBOM per binary, SHA256SUMS and build information.
Honest status: no release build has been published yet. Early-access builds ship with binaries and checksums, without an SBOM.
Go 1.27.3, CGO off, -trimpath, and ten direct dependencies pinned in go.mod and go.sum.
Builds select Go’s FIPS 140-3 cryptographic module, and every pack records whether it was on. That is a build setting, not a FIPS validation of the product.
Every change runs linting and go vet for three operating systems, race tests including an end-to-end test, govulncheck (which fails on any reachable vulnerability), per-package coverage floors and cross builds. Every parser of device data and imported files has fuzz targets.
Every feature had its own code and security review, separate from the work that built it. This is not a third-party audit.
Not yet: release artifacts are not signed, and macOS and Windows builds are not code-signed. Signed offline updates and provenance are planned.

Sign 1,000 devices in one bulk sign-off, with their alerts: about 0.28 s
Log written per 1,000 devices signed: about 1.6 MB
Blind-segment finder, synthetic 40-switch, 38,400-device network: about 135 ms
Rewind: one question answered from snapshots: about 13 ms, flat in log length
Rewind: replay a million-entry log from the start: about 1 s
Rewind snapshots for seven years: about 40 MB
A year of log for the board report: about a second on an Apple M4
Tripwire witness cost: under 1% of a typical switch poll
Program size: about 22 to 25 MB, depending on the platform

Builds: Windows x86-64 and ARM64; Linux x86-64, ARM64 and ARMv7; macOS Apple silicon and Intel. On a virtual machine it runs as a normal program in a Windows or Linux guest, under your own service manager. Virtual machine images and installers are planned.

Questionnaires

Send us your security questionnaire through the contact form. We answer in writing and point to the code or the document behind each answer. The security page lists what we have not done yet, and the security docs carry the detail.

Early access: now taking pilot customers.

Send us your security questionnaire.

We answer in writing and point to the code or document behind each answer. Tell us your switch and firewall models too.

Talk to us about a vendor review Request a demo

What it does on your network, and what it never does.

Why we built it this way

Architecture in plain terms

How work flows

What it reads, and how

What it never does

Data handling and retention

The evidence chain

Supply chain

Measured performance

Where it runs

Send us your security questionnaire.