NIE Operations Console

Trust Anchor v2

Verified Security Posture

Each guarantee below maps to a vulnerability the Trust Anchor work closed. Items marked LIVE are read from this gateway in real time. Items marked PENDING are confirmed design properties whose live signal arrives with the posture endpoint. Hover or tap the marker on any item for what it closes.

🛡

NIE Trust Anchor

The operator control plane that proves NIE is itself protected by the guarantees NIE enforces.

Infrastructure

Live Gateway Status

Real-time health checks against the NIE Gateway deployed on Azure Container Apps. All calls are live HTTPS requests to the production endpoint.

⚙ System Components

NIE Gatewaychecking...

Engine Versionchecking...

Redis (Channel 2)checking...

Event Hubs (Channel 3)checking...

Azure RegionWest US 2

TLS1.3 (Azure Front Door)

🔗 Endpoint

https://nie.xsoccorp.com

Role Management

Define attestation-floor-enforced roles. Each role specifies the minimum hardware trust level and maximum session TTL. Roles are signed with the admin key and cannot be tampered.

🔐 Register New Role

Role ID iRole ID. Pick an existing role to view or re-register its policy, or choose Custom role to define a new one.

Attestation Floor iAttestation floor. Minimum hardware trust a device must prove before this role is granted. SoftwareMin is dev or guest, TpmHardware is a standard TPM-backed device, TpmRequired enforces TPM for privileged roles.

TTL (seconds) iTTL. Maximum lifetime of a session granted under this role before re-attestation is required.

Key iSplit-derived key. The role signing key is the XOR of a browser-generated share and a gateway-generated share, combined only on the server. The full key never exists in the browser and nothing is entered by hand.

📋 Registered Roles

Role ID	Floor	TTL	Status

User Enrollment

Enroll Users and Devices

Enroll users individually or in bulk. Each enrollment issues a device-bound invitation and a portal link. No key material is created on this server: the device derives its own identity inside the WASM sandbox when the user opens the link, so there is nothing here to leak. No password is created at any point. At scale, use CSV batch import or connect your existing IdP directory.

👤 Individual Enrollment

User ID

Device ID

Role

Location

📦 Batch Enrollment (CSV)

Upload a CSV with columns: user_id, device_id, role_id, location. Each row issues a device-bound invitation and a portal link; the device derives its own identity when the user opens it, so nothing here creates key material. Parsing, role validation and duplicate detection run server-side, and one bad row does not discard the rest.

🔗 Directory Connectors

☁

Azure AD / Entra ID

SCIM 2.0. Each synced user is issued a device-bound invitation; they enrol their own device by opening it.

Live

🔒

Okta Directory

SCIM 2.0. Users provisioned on hire, invitations and devices revoked on deactivation.

Live

💼

Workday HR

Auto-provision on hire, auto-revoke on termination. HR-driven lifecycle.

Q3 2026

Connectors use the SCIM 2.0 provisioning standard. A directory push provisions entitlement, not credentials: NIE issues a device-bound invitation and creates no key material, and the device derives its own identity inside the WASM sandbox when the user opens the link. No password is migrated or created, because NIE has none. Deactivating a user in the directory revokes their outstanding invitations and every device they enrolled. Group sync is not implemented, and no directory push can enrol a device on a person's behalf.

👥 Enrolled Users

User	Device	Role	Location	Device FP	Portal Link	Status

Session Monitor

Live Attestation Monitor

Attestation happens on the user's device, not from this console. The user's device collects hardware entropy, derives a DSKAG session key inside the WASM sandbox, signs a sealed token, and sends it to the gateway. The server never constructs tokens. This panel monitors sessions as they are created from user devices in real time.

🔒 Send Portal Link to User

Select an enrolled user and open their portal. The user authenticates on their device via FIDO2 biometric + DSKAG in WASM. Their session appears below automatically.

Select User

📋 Active Sessions Polling every 3s

🔌

Waiting for user attestations...

When a user authenticates via their device portal, their session appears here in real time.

⚠ Architecture Note

The NIE server never constructs, holds, or generates tokens. DSKAG session key derivation executes exclusively inside the WASM sandbox on the user's device from three inputs: hardware platform seed (Web Crypto CSPRNG), biometric factor (FIDO2/WebAuthn), and session nonce. The sealed token crosses the WASM boundary. The server validates the mathematical proof. A breach of this server yields read-only access to validation logs. There is no credential database, no key vault, no token store to compromise.

Authorization

Resource Access Control

Test resource authorization using an active session handle. Every authorization call re-checks the revocation cache. If the device was revoked between attestation and authorization, the call fails immediately.

✅ Authorize Resource Access

Session

Resource ID

Revocation

Three-Channel Device Revocation

Revoke a device across all three channels simultaneously: in-process cache (instant), Redis persistence (channel 2), and Event Hubs fan-out to SIEM/SOC (channel 3). Propagates globally in under 30 seconds.

🚫 Revoke Device

Select User

Reason

Channel 1: In-process cache

Channel 2: Redis persistence

Channel 3: Event Hubs (SIEM/SOC)

Geofencing

Location-Bound Policy Enforcement

Zones are hierarchical physical paths, not coordinates: xsoc/hq/floor-3/secure-room is the unit, so policy reaches a room rather than a circle on a map. A role carries a location requirement; an authorization for that role is denied unless a verified location satisfies it. A location is believed only when it arrives as a witness signed by an enrolled zone emitter, so a device cannot assert where it is.

🌎 Enforcement Status

📍 Configured Zones

Zone Path	Witness Source	Emitters	On Premise	Roles Bound
loading...

An emitter witness proves the device received a live broadcast inside the zone and supports room-level policy. A network witness proves only which network the request arrived from, which is enough for on-premise-only and cannot tell one room from the next.

🔐 Role Zone Policy

Role

Required Zone iRequired zone. The final path segment must equal this. The SCIF case: set it to the room name.

Allowed Locations iAllow patterns. Comma separated. Supports * for one segment, ** for a subtree, and globbing inside a segment such as guest-*.

Denied Locations iDeny patterns. Evaluated before the allow list, so a denied location cannot be rescued by a broader allow rule.

Minimum Assurance iAssurance floor. A policy naming a room should require an emitter witness, since a network witness cannot distinguish rooms.

On Premise Only

📋 Active Policies

Role	Required Zone	Allowed	Denied	Assurance	Remote
loading...

📡 Zone Emitters

An emitter is an ordinary enrolled device marked as broadcasting for a zone. It signs a short-lived witness with the identity key registered at its own enrollment, which the gateway verifies against the stored pairing. There is deliberately no way to create an emitter from nothing: it must enroll first, so no key material is ever generated here.

Device Fingerprint (64 hex)

User Factor Hash (64 hex)

Zone Path

Label

Providence Audit Trail

Hash-Chained Event Log

Every identity event is appended to a hash chain. Each entry commits to the hash of the one before it, so altering an entry breaks every link after it, and because sequence numbers are contiguous a deleted entry leaves a gap that verification names. Entries carry a MAC under a gateway-held key, so writing a plausible record straight into the store does not extend the chain. Verification below is computed from the stored entries rather than asserted here.

🔗 Chain State

📋 Recorded Events

Seq	Time (UTC)	Event	Actor	Target	Outcome	Chain Link
loading...

💬 Session Activity

A live view of what this browser has done since sign-in. It is not the audit trail and it clears on refresh; the recorded events above are the durable record.

Waiting for events...