Identity-Aware Authorization for Operational Technology
BASIS (Building Automation Secure Identity Service) is an open-source authorization ecosystem for operational technology environments — commercial buildings, hospitals, schools, warehouses, and data centers. The project explores how identity-aware authorization can be applied consistently across operational systems while preserving clear trust boundaries, deterministic policy evaluation, and structured auditability. Two runtime components are now released: basis-core, a deterministic authorization kernel, and basis-gateway, the identity-aware enforcement gateway that deploys it.
pip install basis-corePython 3.10+ · Pydantic ≥ 2.0 · MIT
The research proof of concept: live telemetry streaming over an authenticated WebSocket. The Data Center section shows rack inlet temperatures, hot/cold aisle thermals, and CRAC cooling status from the simulator.
The problem
The absence of identity controls in OT is an operational problem
Perimeter-based, not action-based access
A technician with read-only dashboard access can frequently issue override commands — because access control is coarse-grained and perimeter-based. There is no authoritative record of who changed a setpoint and when.
No unified policy layer
Multiple protocols — Modbus, BACnet, MQTT — each have separate or absent access control mechanisms with no unified policy layer. A compromised credential can grant access to everything the broker will accept.
AI infrastructure raises the stakes
GPU clusters are thermally critical systems, and the cooling and power infrastructure keeping them alive — CRAC units, PDUs, UPS systems — is OT. An unauthorized command to any of these, without identity verification or audit, can cascade into rack shutdowns.
One policy surface, one audit record
A kernel-based model gates every action through the same evaluation path: PolicyEngine evaluation → AuditEvent emission → adapter dispatch. A Modbus command and an MQTT publish cross the same authorization boundary and produce the same structured audit record.
Project scope
What BASIS is — and is not
The credibility of this work depends on being explicit about its boundaries. These are not limitations to be overcome — they are deliberate scope decisions.
BASIS is
An open-source authorization ecosystem for OT
Basis Foundation governs the BASIS ecosystem — a collection of components designed to provide identity-aware authorization for operational technology environments. The ecosystem defines kernel boundaries, domain contracts, and architectural patterns.
Grounded in production engineering analysis
The architecture research (basis-architecture) examines what identity-aware authorization actually requires in OT: trust boundary analysis, synchronization constraints, governance complexity, and operational realities. The white paper does not minimize these burdens.
basis-core is
A released Python authorization kernel
basis-core v0.1.0 is a pip-installable Python library providing PolicyEngine, EnforcementPoint, domain types, AuditEvent contracts, and AdapterBase. 625 passing tests. Stabilized public API. MIT license.
Protocol-agnostic and infrastructure-independent
The kernel evaluates authorization decisions without requiring a specific transport, database, or identity provider. It defines contracts — not implementations. Integration with specific infrastructure is the concern of adapters and services built on top of the kernel.
basis-gateway is
A released enforcement gateway
basis-gateway v0.1.0 provides OIDC authentication, JWT validation, identity normalization, HTTP request lifecycle, and gateway audit events. It is the enforcement boundary that deploys basis-core into production environments.
The component that owns what the kernel refuses
basis-core deliberately excludes authentication, transport, and identity-provider concerns. basis-gateway exists to own those responsibilities so the kernel can remain transport-agnostic, infrastructure-independent, and deeply portable.
BASIS is not
Production-ready OT security software
The proof of concept has not been validated against real OT hardware. Production readiness requires sustained validation against real operational conditions that has not occurred.
A claim that identity centralization solves OT security
Identity-aware authorization addresses a specific structural gap. It does not address firmware vulnerabilities, physical security, protocol weaknesses, or the many other dimensions of OT security that matter in practice.
A universal OT authorization solution
Commercial buildings, industrial process control, utilities, and manufacturing share authorization concerns but differ substantially in latency tolerances, safety integration, regulatory context, and governance structure.
A commercial product
BASIS is an open-source research and engineering effort. BASAuth — a future commercial entity in this space — is not yet operating.
Ecosystem
Basis Foundation, BASIS Core Services Distribution, and BASAuth
BASIS is an ecosystem with defined layers. Basis Foundation is the governing open-source body. The BASIS Core Services Distribution is the collection of components implementing the authorization model — now including basis-adapters, the protocol/platform normalization layer. BASAuth is a future commercial entity that is not yet operating.
Basis Foundation
ActiveOpen-source governing body. Owns basis-core, basis-architecture, and this website. Defines kernel boundaries, domain contracts, and ecosystem principles.
basis-core (MIT) · basis-architecture (Apache 2.0)
BASIS Core Services Distribution
In progressThe set of components that implement the full authorization model. basis-core and basis-gateway are the first two released runtime components, and basis-adapters is the public protocol/platform normalization layer. The remaining components are planned.
basis-core
Released — v0.1.0
Authorization kernel: PolicyEngine, EnforcementPoint, domain types, AuditEvent contracts
basis-gateway
Released — v0.1.0
Identity-aware enforcement gateway: OIDC authentication, JWT validation, identity normalization, gateway audit events
basis-adapters
Public — v0.1.0 RC
Protocol/platform normalization: REST, BACnet, Modbus, OPC UA, MQTT, DNP3, IEC 61850, KNX, Niagara — normalization-complete
basis-console
Planned
Operator console for policy management and audit review
basis-deploy
Planned
Deployment tooling and reference configurations
basis-schemas
Planned
Canonical schema definitions for interoperability
BASAuth
Not yet operatingA future commercial entity in the BASIS ecosystem. Not yet operating. No products or services are currently available.
Protocol normalization layer
basis-adapters normalizes OT protocol and platform operations into a shared authorization request model while preserving protocol evidence for auditability. The completed set covers REST, BACnet, Modbus, OPC UA, MQTT, DNP3, IEC 61850, KNX, and Niagara.
Adapters normalize. Gateway enforces. Kernel evaluates.
Protocol normalization reference →basis-core
What the authorization kernel provides
basis-core is a Python library. Its public API is stabilized with a governed breaking-change process, ADR-reviewed changes, and contract snapshot tests.
PolicyEngine
Evaluates a chain of policies against a DecisionRequest. DENY short-circuits. NOT_APPLICABLE defaults to DENY. Exceptions produce fail-closed DENY. Returns a DecisionResponse with outcome and rationale.
EnforcementPoint
The integration boundary between the kernel and the caller. Accepts a DecisionRequest, invokes the PolicyEngine, emits an AuditEvent via the configured AuditWriter, and returns the decision.
Domain types
Subject, Resource, Action, IdentityContext — the normalized types that cross the kernel boundary. Protocol-agnostic by construction: a Modbus command and an MQTT publish share the same Subject/Resource/Action representation.
AuditEvent contracts
AuditEvent is a defined schema, not a log format. Every decision — allowed and denied — produces an AuditEvent. The AuditWriter protocol decouples the kernel from any specific persistence mechanism.
AdapterBase
The extension point for protocol adapters. Adapters implement AdapterBase and call the EnforcementPoint. The kernel has no knowledge of what the adapter connects to.
PolicyBase
The extension point for custom policies. Policies implement PolicyBase and return ALLOW, DENY, or NOT_APPLICABLE. Exceptions are caught by the engine and converted to fail-closed DENY.
Evaluation semantics
- DENY short-circuits: the first DENY in the policy chain ends evaluation
- NOT_APPLICABLE → DENY: a policy that declines to decide is not a pass
- Exception → DENY: any error in policy evaluation fails closed
- Empty policy set → DENY: no policy is not a default allow
Kernel design properties
How basis-core behaves, by construction
These properties are not aspirations or configuration options — they are structural properties of the kernel that hold across all callers.
Deterministic evaluation
PolicyEngine evaluation is deterministic: the same subject, resource, action, and context always produce the same decision. There is no probabilistic or time-dependent logic in the evaluation path.
Fail-closed enforcement
Any exception during policy evaluation produces DENY. An empty policy set produces DENY. A NOT_APPLICABLE result produces DENY. The kernel cannot be left in an open state by error or omission.
Auditability as a contract
AuditEvent is a first-class domain type with a defined schema. Every authorization decision — allowed and denied — produces an AuditEvent. The audit record is a contract, not an implementation detail.
Protocol agnosticism
The kernel operates on abstract Subject, Resource, Action, and IdentityContext types. It has no knowledge of HTTP, MQTT, Modbus, or any transport protocol. Protocol-specific logic belongs in adapters, not in the kernel.
Extension safety
Custom policies extend PolicyBase. Custom adapters extend AdapterBase. The extension points are narrow and typed — a policy that raises an exception is caught by the engine and converted to a fail-closed DENY.
Kernel isolation
basis-core has no runtime dependency on a specific identity provider, database, or network service. It evaluates decisions in-process, with no I/O required. Infrastructure dependencies are the concern of the caller.
Research proof of concept
What the PoC validated
basis-poc is the research implementation that preceded basis-core. It is a Docker Compose stack — Keycloak, FastAPI, Mosquitto, React, SQLite — built to validate that identity-aware authorization patterns are implementable and coherent in an OT context. basis-core is the authorization kernel extracted from this work.
Step 01
Live telemetry dashboard
HVAC temperature, CO₂ air quality, and occupancy telemetry arrive via authenticated WebSocket. The Data Center section streams rack inlet temperatures, hot/cold aisle thermals, CRAC cooling unit status, PDU load, UPS battery state, and environmental sensors — all from the simulator.
Step 02
Authorization boundary enforced
Alice (viewer) encounters the policy boundary. The control panel shows it's locked. A direct API call to any command endpoint with her token returns 403 — the policy boundary is enforced server-side regardless of what the UI renders. The denial is written to the audit log.
Step 03
Audit trail
Carol (admin) reads the audit log. Every action — bob's successful setpoint change, alice's 403, telemetry session connects and disconnects — appears as a timestamped event with subject, action, resource, and outcome. Denied events are as important as allowed ones.
Open research areas
Unresolved architectural questions
The PoC demonstrates that the core concepts are implementable. These are the harder problems that remain open — not a product roadmap. Each reflects a genuine tension in deploying distributed authorization infrastructure in OT environments.
Synchronization and consistency
Bounded policy inconsistency across the enforcement fleet
Edge enforcement points running local policy caches will reflect heterogeneous policy versions during and after synchronization. This is the normal operating state of any distributed authorization system — not an edge case to be solved away.
Credential lifecycle
Revocation latency within the synchronization window
A revoked credential may remain valid at edge enforcement points until the next successful policy sync. Whether that window is acceptable depends on the circumstances. The architecture makes this tradeoff explicit; it cannot collapse the window to zero.
Governance fragmentation
Cross-domain authorization governance
The identity provider, policy engine, enforcement points, and protocol adapters typically span administrative domains that do not naturally coordinate. No existing governance framework fully addresses this. It must be designed deliberately for each deployment.
Fail behavior
Fail-open vs. fail-closed under enforcement point faults
Neither behavior is universally correct. Fail-closed authorization that blocks an emergency command is not a safe default. The deployment must negotiate this among operations, security, and safety stakeholders — the architecture frames the decision, it cannot make it.
Device identity at scale
Certificate lifecycle across multi-decade OT assets
A certificate infrastructure designed for three-year lifetimes operates through multiple rotation cycles during the multi-decade operational life of a building controller. Lifecycle planning for this is substantially more demanding than point-in-time design.
Lifecycle sustainability
Accumulated maintenance obligations over time
Policy that accurately reflected the access model at initial deployment becomes stale as organizational structures change. Protocol adapters may normalize device models incorrectly after firmware updates. These are the normal trajectory of any operational system sustained across real OT environments.
Repositories
Released components, architecture research, and proof of concept
The ecosystem spans five public repositories. basis-core is the authorization kernel. basis-gateway is the identity-aware enforcement gateway. basis-adapters is the protocol/platform normalization layer. basis-architecture is the intellectual center. basis-poc is the original research implementation.
basis-core — Authorization kernel→
The v0.1.0 Python library: PolicyEngine, EnforcementPoint, domain types (Subject, Resource, Action), AuditEvent contracts, and AdapterBase. Stabilized public API, 625 passing tests, governed breaking-change process.
basis-gateway — Identity-aware enforcement gateway→
The v0.1.0 enforcement gateway: OIDC authentication, JWT validation, identity normalization, HTTP request lifecycle, correlation IDs, gateway audit events, and strict fail-closed behavior. Embeds basis-core.
basis-adapters — Protocol/platform normalization→
The v0.1.0 release-candidate normalization layer: REST, BACnet, Modbus, OPC UA, MQTT, DNP3, IEC 61850, KNX, and Niagara normalize into a shared authorization request while protocol evidence is preserved. Normalization-complete, not wire-protocol complete.
basis-architecture — White paper and systems analysis→
"Identity-Aware Authorization for Operational Technology" — trust boundary analysis, production engineering constraints, threat modeling, synchronization complexity, governance fragmentation, and architecture principles.
White paper (full text)→
The flagship technical document. Covers the architectural model, OT trust boundaries, production realities, threat modeling, and why the architecture redistributes complexity rather than eliminating it.
basis-poc — Research proof of concept→
The original research PoC: Docker Compose environment, Keycloak, FastAPI with JWT middleware, Mosquitto, React dashboard, SQLite audit log, and simulated HVAC/data-center devices. A research artifact, not the canonical implementation.
Architecture Decision Records (basis-core)→
ADRs from the basis-core repo — what was decided, why, and what alternatives were considered: repository purpose, modular monolith structure, core boundary, and adapter placement.
Open source — five public repositories
basis-core is the released authorization kernel (MIT). basis-gateway is the released enforcement gateway (MIT). basis-adapters is the protocol/platform normalization layer (Apache 2.0). basis-architecture contains the white paper and systems analysis (Apache 2.0). basis-poc is the original research implementation.