How it works

No PII at the edge

TrustGate's architectural promise: no personal data is stored on the door device. Credentials flow through the device, get verified by Broker, and produce an ALLOW / DENY decision that's logged centrally. The device itself holds no names, no dates of birth, no identifiers — a stolen or compromised door yields no PII.

Site → Zone → Door hierarchy

Operators configure a hierarchy: sites (a building, a campus), zones (floors, departments), and doors (specific entry points). Each door inherits verification rules from its parent zone and site, with door-specific overrides. A zone-level policy change ripples to every door in that zone.

Edge flow

A user approaches the door and presents a credential (QR scan). The door device forwards the presentation request to a nearby TrustGate service, which creates a Broker session, receives the VP token, validates via Broker, optionally evaluates a Policy Engine rule, and returns ALLOW or DENY. The door actuator opens or stays locked. Total round-trip: well under a second.

Session-scoped claim caching

For repeat-use cases (someone re-entering within a short window), TrustGate can cache the verification result for a configurable TTL. The cache is session-scoped and device-local; caches clear when the door reboots or on a force-cycle command. PII is not cached — only an anonymous "last session decided ALLOW, expires at T" marker.

Audit log

Every entry attempt is written to an append-only access_log table: timestamp, zone, door, decision (allow/deny), anonymous session ID. Operators can reconstruct an incident timeline from the log without ever having stored PII. Retention is operator-configurable (GDPR, legal hold).

Delegated verification

TrustGate doesn't re-implement OpenID4VP — it delegates to Broker. Every Broker improvement (new formats, more verifiers, hardened replay-detection) automatically benefits every TrustGate deployment. The device stays thin.