RFD 536 NIST SP 800-53 (Rev. 5) and the Oxide Rack

NIST Control Statement:

Automatically [Selection: remove; disable] temporary and emergency accounts after [Assignment: organization-defined time period for each type of account].

Oxide Description:

The Oxide control plane does not provide a native time-based account expiration mechanism; temporary and emergency accounts are not a distinct account category with built-in automatic removal or disablement.

For Silos configured with SCIM, automated account lifecycle management (including disablement of temporary or emergency accounts after a defined period) can be driven by the customer’s identity provider. The IdP is authoritative for account state; when an account is disabled or deprovisioned in the IdP, the change is reflected in the Oxide Silo via SCIM.

For Silos using SAML IdP authentication without SCIM, temporary and emergency account management must be performed at the IdP. Oxide does not perform account management beyond IdP authentication for these Silos.

For Silos using local authentication, Silo Administrators must manually remove or disable temporary and emergency accounts via the API. No automated expiration timer is available. When immediate access revocation is required, Silo Administrators can terminate all active web console sessions and API access tokens for a user in a single operation.

Oxide Remarks:

Oxide provides the session termination and SCIM integration mechanisms. The customer is responsible for the following:

For SCIM-configured Silos: configure the identity provider to automatically disable or remove temporary and emergency accounts after the organization-defined time period. Document the time period and IdP configuration in the SSP.

For IdP Silos without SCIM: implement temporary and emergency account management policy at the IdP. Document procedures for timely account disablement in the SSP.

For local-auth Silos: establish and follow manual procedures for removing or disabling temporary and emergency accounts within the organization-defined time period. Use the Oxide API to terminate all active sessions when immediate revocation is required.

References:

NIST Control Statement:

Disable accounts within [Assignment: organization-defined time period] when the accounts:

Oxide Description:

Account disablement capabilities vary by Silo authentication configuration. For SCIM-configured Silos, account disable and re-enable is supported directly via the identity provider across all four disable conditions. For IdP Silos without SCIM, account lifecycle is managed at the IdP. For local-auth Silos, Silo Administrators must perform disablement manually via the API; no native expiration, policy-enforcement, or inactivity timer is available. For all Silo types, Silo Administrators can immediately terminate all active web console sessions and API access tokens for a user in a single operation when access revocation is required.

Oxide Remarks:

Oxide provides session termination, account removal, and SCIM integration mechanisms. The customer is responsible for the following:

For SCIM-configured Silos: configure the identity provider to automatically disable accounts under each of the four conditions (expiration, disassociation, policy violation, inactivity) within the organization-defined time period. Document IdP configuration and time periods in the SSP.

For IdP Silos without SCIM: implement account disablement procedures at the IdP for each condition. Document procedures and time periods in the SSP.

For local-auth Silos: establish and follow manual procedures for disabling accounts within the organization-defined time period for each condition. Use the Oxide API to terminate all active sessions and remove accounts. Monitor the audit log to detect inactive accounts and implement external automation if the organization requires automated disablement.

References:

NIST Control Statement:

Automatically audit account creation, modification, enabling, disabling, and removal actions.

Oxide Description:

The Oxide control plane automatically generates audit log records for account creation, modification, and removal actions across all Silo types. Each record includes the caller identity, source IP, timestamp, affected resource UUID, and operation result. These events are captured without requiring any administrator configuration.

Account enabling is audited when a Silo Administrator grants a role assignment to a previously role-less user. Account disablement is not a distinct auditable event for local-auth Silos, as the Oxide control plane has no dedicated disable operation for these accounts; the individual operations that constitute effective disablement (password reset and session termination) each generate their own audit records. For SCIM-configured Silos, account state changes driven by the identity provider are reflected in audit records for the corresponding API operations.

The Oxide control plane does not natively notify personnel or roles when account actions occur; its webhook alert mechanism currently carries only hardware power-shelf PSU events and liveness probes, not account events. Organizations must implement notification by forwarding the audit log to a SIEM and configuring alerting rules for account lifecycle events.

Oxide Remarks:

Oxide automatically audits account creation, modification, and removal. The customer is responsible for the notification requirement: configure audit log forwarding to a SIEM and establish alerting rules to notify organization-defined personnel or roles when account lifecycle events occur. Customer-side notification procedures must be documented in the SSP.

References:

NIST Control Statement:

Require that users log out when [Assignment: organization-defined time period of expected inactivity or description of when to log out].

Oxide Description:

The Oxide control plane enforces inactivity logout for web console sessions automatically. Web console sessions are terminated after eight hours of inactivity (idle timeout) and unconditionally after twenty-four hours from creation (absolute timeout), regardless of activity. These values are not currently configurable by administrators; support for operator-configured timeout values is planned.

API access tokens do not have an inactivity-based logout mechanism. Silo Administrators can set an upper bound on the maximum validity period for API access tokens using the auth_settings_update API, after which the token expires and the user must re-authenticate. Users can also delete their own API access tokens at any time.

Oxide Remarks:

Oxide enforces automatic inactivity logout for web console sessions. The customer is responsible for the following:

Configure the maximum API access token validity period using auth_settings_update to align with the organization-defined inactivity period. Document the configured value in the SSP.

Inactivity-based automatic expiration of API access tokens is not supported; organizations should treat the maximum validity period setting as a compensating control for long-lived tokens.

References:

NIST Control Statement:

Enforce [Assignment: organization-defined circumstances and/or usage conditions] for [Assignment: organization-defined system accounts].

Oxide Description:

The Oxide control plane enforces usage conditions for accounts through role-based access control (RBAC). Each account’s permitted operations are constrained by the roles assigned to it: Fleet Admin, Fleet Collaborator, Fleet Viewer, Silo Admin, Silo Collaborator, Silo Limited Collaborator, Silo Viewer, Project Admin, Project Collaborator, Project Limited Collaborator, or Project Viewer. The control plane enforces these role boundaries on every API request; users cannot perform operations outside the scope of their assigned roles regardless of how the request is made. Silo membership itself is a usage condition: accounts have no access to a Silo they are not a member of.

For Silos configured with SAML IdP authentication, IdP-provided attributes can be mapped to Oxide roles, enabling the IdP to enforce additional usage conditions (such as group membership, department, or contract status) that are expressed as role assignments in Oxide. For SCIM-configured Silos, role assignments can be updated dynamically as conditions change in the IdP.

The Oxide control plane does not natively enforce time-of-day restrictions, network location restrictions, device type restrictions, or concurrent session limits for accounts.

Oxide Remarks:

Oxide enforces role-based usage conditions for all accounts. The customer is responsible for the following:

Define the organization-specific usage conditions applicable to each account type and document them in the SSP. Implement conditions that the Oxide control plane does not enforce natively (time-of-day, location, device type, concurrent sessions) at the IdP for SAML or SCIM-configured Silos, or via external network controls. Assign roles that reflect the least-privilege usage conditions required for each account.

References:

NIST Control Statement:

Oxide Description:

Oxide provides two complementary data sources for account usage monitoring.

The audit log records every state-changing control plane operation as a structured event, including all account-related activity: authentication attempts (success and failure), account creation and modification, role assignment changes, session initiation and termination, and API token creation and deletion. Each record includes the caller identity, source IP address, timestamp, affected resource UUID, and operation result. The audit log is the primary data source for detecting atypical account behavior and satisfies parts (a) and (b) of this control when ingested into a customer-operated SIEM.

Oxide also provides Oximeter, an integrated metrics system queryable via OxQL (Oximeter Query Language). Oximeter collects infrastructure telemetry (VM CPU, memory, network throughput, disk I/O, and hardware sensor data) scoped to resources, not to user accounts directly. When correlated with audit log records (which identify the account that provisioned or modified a resource), Oximeter metrics can serve as a supplementary signal: unusual resource consumption patterns on instances associated with a given account may indicate atypical usage warranting investigation.

Oxide does not natively detect atypical usage patterns, generate alerts, or report anomalies to personnel.

Oxide Remarks:

The audit log is the authoritative source for account activity events and should be the primary input to SIEM-based account monitoring. Oximeter metrics are infrastructure-scoped and do not directly record account actions; their value for this control is in correlation; anomalous resource activity on instances can be traced back to the provisioning account via audit records.

The customer is responsible for the following: configure export of the Oxide audit log to a SIEM or log management system; optionally integrate Oximeter metrics via OxQL for correlated anomaly detection; define organization-specific atypical usage patterns and detection thresholds; implement alerting rules; and establish procedures for reporting atypical usage to designated personnel or roles.

References:

NIST Control Statement:

Enforce [Assignment: organization-defined organization-defined discretionary access control policy] over the set of covered subjects and objects specified in the policy, and where the policy specifies that a subject that has been granted access to information can do one or more of the following:

Oxide Description:

Oxide implements discretionary access control by allowing designated administrators to grant and revoke access to resources within their scope. Silo Admins control membership and role assignments within their Silo, including which users can access the Silo and at what privilege level. Project Admins control role assignments within their Project, determining which users can manage or use compute, storage, and networking resources in that Project.

Administrators can delegate access to other users up to but not exceeding their own privilege level within the same scope. Silo role assignments are inherited by all Projects within that Silo, so a Silo-level grant propagates downward through the hierarchy. The control plane enforces these boundaries; a Project Admin cannot grant access outside the Project they administer, and a Silo Admin cannot grant access outside their Silo.

Oxide Remarks:

The customer is responsible for designating which users hold Silo Admin and Project Admin roles, and for ensuring those administrators exercise their discretionary authority consistent with the organization’s least-privilege and need-to-know policies.

References:

NIST Control Statement:

Enforce a role-based access control policy over defined subjects and objects and control access based upon [Assignment: organization-defined organization-defined roles and users authorized to assume such roles].

Oxide Description:

Oxide enforces role-based access control (RBAC) with a defined set of roles, each carrying a fixed set of permitted operations. Roles are not configurable by customers; permissions are determined by Oxide and enforced uniformly across all deployments.

Roles are defined at three resource scopes:

Fleet scope (rack-wide): Fleet Admin can manage all Silos, users, and system configuration. Fleet Collaborator can create and manage Silos. Fleet Viewer has read-only access to Fleet-level resources.

Silo scope (tenant boundary): Silo Admin can manage Silo membership, IAM policies, identity provider configuration, and all Projects within the Silo. Silo Collaborator can create and manage Projects and holds the Admin role on every Project in the Silo. Silo Limited Collaborator holds the Limited Collaborator role on every Project in the Silo. Silo Viewer has read-only access to Silo-level resources.

Project scope (workload boundary): Project Admin can manage all resources within the Project and grant Project-level roles. Project Collaborator can create and manage all Project resources, including VPC networking (subnets, routers, internet gateways, and firewall rules). Project Limited Collaborator can manage instances, disks, snapshots, images, and instance-level networking such as floating IPs, but cannot change VPC networking configuration. Project Viewer has read-only access to Project resources.

Role assignments are stored in the IAM policy for each resource. On every API request, the control plane evaluates the caller’s role assignments against the policy for the targeted resource and denies operations not permitted by those roles. Silo-level role assignments are inherited by all Projects within that Silo.

Oxide Remarks:

The customer is responsible for assigning users to roles in accordance with their access authorization decisions. The role definitions and enforcement logic are provider-implemented and not subject to customer modification.

References:

NIST Control Statement:

Prevent encrypted information from bypassing [Assignment: organization-defined information flow control mechanisms] by [Selection (one or more): decrypting the information; blocking the flow of the encrypted information; terminating communications sessions attempting to pass encrypted information; [Assignment: organization-defined procedure or method] ].

Oxide Description:

This control does not apply to the Oxide Cloud Computer component. Oxide’s network enforcement (OPTE and VPC firewall rules) operates at Layer 3/4; it enforces flows based on IP address, protocol, and port. Oxide does not perform content inspection on tenant network traffic and does not provide a mechanism to detect or block encrypted information flows based on payload content.

Oxide Remarks:

If the customer’s security policy requires that encrypted traffic not bypass content-inspection mechanisms, the customer must implement that capability within their network architecture, for example by routing traffic through an inspection appliance deployed as a guest workload or at the network boundary. This is outside the scope of the Oxide component.

NIST Control Statement:

Separate information flows logically or physically using [Assignment: organization-defined organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization-defined required separations by types of information].

Oxide Description:

Oxide provides three distinct mechanisms for separating information flows by type: network-layer VPC isolation, management network separation, and control plane Silo boundaries.

At the network layer, OPTE (Oxide Packet Transformation Engine) enforces logical separation between VPCs at the hypervisor. Traffic does not cross VPC boundaries unless the customer explicitly configures routing or peering. Within a VPC, customers define firewall rules that restrict flows between subnets and instances; OPTE enforces these rules in the network fabric and instances cannot bypass them. These primitives allow customers to express information separation requirements in terms of network topology — for example, by placing workloads of different sensitivity levels in separate VPCs with restricted egress.

Control plane communications are separated from tenant data flows at the network layer. Nexus, sled agents, and supporting control plane services communicate over an internal management network not reachable from tenant workloads or external users. Tenant-originated traffic cannot reach or observe management flows.

At the control plane layer, Silo boundaries logically separate organizational data. Users and resources in one Silo cannot access or enumerate resources in another Silo, and a Silo Admin in one Silo has no visibility into other Silos' resources.

Oxide Remarks:

The customer is responsible for defining which types of information require separation and expressing those requirements as VPC topology and firewall policy. Oxide enforces the boundaries the customer configures; it does not prescribe a separation scheme. SSP authors should document their VPC and Silo architecture in terms of the information types they are separating and verify that the configured rules are sufficient for their authorization requirements.

References:

NIST Control Statement:

Prevent the following software from executing at higher privilege levels than users executing the software: [Assignment: organization-defined software].

Oxide Description:

Oxide enforces a privilege boundary between guest VM workloads and the host system. Guest workloads run inside bhyve VMs managed by Propolis; they execute at guest privilege levels and cannot escalate to host OS (Helios) or hypervisor privilege levels. A process running inside a VM, regardless of its privilege level within the guest OS, cannot execute code at host or rack-management privilege levels.

Oxide does not manage operating system environments within guest VMs. Privilege levels for software executing inside a VM (including the guest OS kernel, system services, and applications) are the responsibility of the tenant operating the VM.

Oxide Remarks:

Oxide implements the privilege boundary at the hypervisor layer. The customer is responsible for controlling privilege levels for software executing within their guest VMs, including restricting use of elevated privileges (e.g., root, setuid binaries, privileged service accounts) to the minimum required for each workload.

NIST Control Statement:

Log the execution of privileged functions.

Oxide Description:

Oxide logs privileged function use for operations performed through the control plane API. Privileged functions include Fleet-level operations (Silo creation and deletion, system configuration, user management), Silo-level operations (IAM policy changes, identity provider configuration, Project management), and all resource provisioning and configuration operations. Every API call generates a structured audit record including the caller identity, source IP address, timestamp, affected resource UUID, and operation result. Privileged operations performed by Fleet Admins and Silo Admins are distinguishable in the audit stream by operation type and resource scope.

The rack also exposes a physical technician port providing SSH access to privileged system functions and a TCP proxy to the control plane API. The SSH path is reserved for Oxide support personnel and is authenticated via SSH keys stored on YubiKey hardware security devices pre-registered in Omicron; the API proxy path uses the same HTTPS endpoint and API credentials as the external API. Technician port shell sessions and the privileged operations performed through them are not currently captured in the control plane audit log; API calls made through the technician port’s API proxy are ordinary control plane API calls and are audited like any other.

Oxide Remarks:

API-based privileged function use is fully logged. The gap is the technician port shell path: privileged operations performed by Oxide support through SSH to the switch zone are not captured in the audit log (API calls made through the port’s API proxy are audited normally). Shell access is restricted to Oxide support personnel using hardware-bound YubiKey credentials; YubiKeys require PIN entry before use, making this authentication two-factor (hardware token plus PIN). This limits both the population of actors and requires strong authentication on the only path that bypasses audit logging. SSP authors should document this gap and assess residual risk in the context of their authorization boundary. Organizations with strict privileged function logging requirements should confirm with Oxide whether technician port audit logging is planned.

References:

NIST Control Statement:

Prevent non-privileged users from executing privileged functions.

Oxide Description:

The Oxide control plane enforces a strict boundary between privileged and non-privileged functions. Privileged functions (including Silo and Project IAM policy changes, identity provider configuration, Silo membership management, and Fleet-level system operations) require an Admin role at the appropriate scope. Users holding only Viewer, Limited Collaborator, or Collaborator roles cannot invoke these operations; the control plane denies such requests regardless of how they are made.

This prohibition is structural, not configurable. Non-privileged users have no path to execute privileged functions through misconfiguration or omission: the role check is enforced on every API request before the operation is permitted. A Project Collaborator cannot perform Project Admin operations; a Silo Viewer cannot perform Silo Admin operations; and no Silo-scoped role grants Fleet-level privileges.

References:

NIST Control Statement:

Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

Oxide Description:

This control does not apply to the Oxide Cloud Computer. The rack has no local display or interactive console; there is no screen to conceal with a pattern-hiding image.

NIST Control Statement:

Provide a logout capability for user-initiated communications sessions whenever authentication is used to gain access to [Assignment: organization-defined information resources].

Oxide Description:

Oxide provides user-initiated session termination for both access methods. Users can log out of the web console at any time, which immediately invalidates the current session. Users can list their active API access tokens and delete individual tokens via the API, terminating those sessions on demand.

Users cannot enumerate their other active web console sessions; only the current session is visible and terminable by the user directly. Silo Administrators can terminate all active sessions for a user via the API, terminating all active web console sessions and API tokens.

Oxide Remarks:

The gap in user-initiated logout is web console session enumeration: users cannot list their other active web console sessions and therefore cannot terminate them directly (omicron#7816). A user who suspects an active session is compromised should contact their Silo Administrator to terminate all sessions. SSP authors should document this limitation and note the administrative remediation path.

References:

NIST Control Statement:

Employ automated mechanisms to monitor and control remote access methods.

Oxide Description:

Oxide monitors and controls remote access sessions through the control plane. Every remote access session (whether initiated via the web console, REST API, or CLI) is authenticated before access is granted and generates audit records for all operations performed during the session. Audit records include the caller identity, source IP address, timestamp, affected resource UUID, and operation result, providing a complete record of remote session activity.

Silo Administrators can terminate any active user session, including web console sessions and API access tokens, via the API, providing real-time control over remote access. Web console sessions are automatically terminated after 8 hours of inactivity or 24 hours absolute. Silo Administrators can configure the maximum validity period for API access tokens.

Oxide Remarks:

Oxide provides the audit data and session termination capability. The customer is responsible for actively monitoring remote access sessions by ingesting the audit log into a SIEM, defining thresholds for anomalous remote access activity, and responding to detected anomalies.

References:

NIST Control Statement:

Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.

Oxide Description:

Oxide protects the confidentiality and integrity of all remote access sessions using TLS. All connections to the control plane (via the web console, REST API, or CLI) are encrypted with TLS 1.2 or TLS 1.3. Unencrypted connections are not accepted. This encryption is enforced by Oxide and requires no customer configuration.

NIST Control Statement:

Route remote accesses through authorized and managed network access control points.

Oxide Description:

This control does not apply to the Oxide Cloud Computer component. The Oxide rack is an on-premises system deployed within a customer-controlled facility. Oxide has no role in the network path between remote users and the rack; the managed access control points through which remote access is routed are customer network infrastructure.

Oxide Remarks:

The customer is responsible for ensuring that remote access to the Oxide rack is routed through managed network access control points (e.g., VPN gateway, jump host, or network access control infrastructure) consistent with their authorization boundary requirements. SSP authors must document the managed access control architecture in their system-level network controls.

NIST Control Statement:

Protect wireless access to the system using authentication of [Selection (one or more): users; devices] and encryption.

Oxide Description:

This control does not apply to the Oxide Cloud Computer. The rack has no wireless network interfaces; wireless authentication and encryption requirements are not applicable.

NIST Control Statement:

Disable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.

Oxide Description:

This control does not apply to the Oxide Cloud Computer. The rack has no wireless network interfaces; wireless connection disabling requirements are not applicable.

NIST Control Statement:

Generate audit records containing the following additional information: [Assignment: organization-defined additional information].

Oxide Description:

The Oxide audit log schema is fixed; customers cannot configure it to add or remove fields. Every audit record includes the six baseline fields required by AU-3 (timestamp, actor, source IP, resource UUID, operation type, and outcome) plus the full resource identifier path, enabling correlation across resource hierarchy (Fleet, Silo, Project, resource).

If an organization requires additional information in audit records beyond what the Oxide audit log provides (such as request parameters, before/after resource state, or organization-defined annotations), that enrichment must be performed by the customer after exporting the audit log to their SIEM or log management system.

Oxide Remarks:

SSP authors should review the Oxide audit log schema against their organization-defined additional information requirements for AU-3(1) and document any gap. If required fields are absent, the customer must implement enrichment post-export.

References:

NIST Control Statement:

Transfer audit logs [Assignment: organization-defined frequency] to a different system, system component, or media other than the system or system component conducting the logging.

Oxide Description:

Oxide does not automatically transfer audit records to alternate storage. The audit log is stored internally for 90 days and then deleted; Oxide does not operate or provide an alternate storage facility.

Oxide exposes the audit log via API, enabling customer-operated tooling to retrieve records and transfer them to alternate storage (SIEM, object storage, log management system, or other external media). Customers must implement this retrieval and transfer process to satisfy AU-4(1).

Oxide Remarks:

The customer is responsible for operating the alternate storage system and implementing the process to retrieve audit records from Oxide and transfer them before the 90-day internal retention window expires. SSP authors must document the alternate storage system, transfer frequency, and the mechanism used to ensure no records are missed between retrieval cycles.

References:

NIST Control Statement:

Provide a warning to [Assignment: organization-defined personnel, roles, and/or locations] within [Assignment: organization-defined time period] when allocated audit log storage volume reaches [Assignment: organization-defined percentage] of repository maximum audit log storage capacity.

Oxide Description:

Oxide does not provide a configurable storage capacity warning for the audit log. Oxide’s internal audit log storage is time-based rather than size-based: records are retained for 90 days and then deleted regardless of storage utilization. There is no threshold at which the system warns that capacity is approaching exhaustion, because unbounded growth is prevented by the retention policy rather than a capacity limit.

Oxide does not provide warnings to customers when the 90-day retention window is approaching for unexported records. Customers are responsible for monitoring their own export pipelines to ensure records are retrieved before deletion.

Oxide Remarks:

The traditional storage capacity warning model does not apply to Oxide’s time-based retention. The customer’s equivalent obligation is ensuring their export pipeline is operating continuously so that records are archived before the 90-day window expires. SSP authors should document the monitoring controls the customer uses to detect export pipeline failures.

References:

NIST Control Statement:

Provide an alert within [Assignment: organization-defined real-time period] to [Assignment: organization-defined personnel, roles, and/or locations] when the following audit failure events occur: [Assignment: organization-defined audit logging failure events requiring real-time alerts].

Oxide Description:

Oxide does not provide real-time alerts to customers when internal audit processing failures occur. Oxide’s two-stage write model and incomplete-entry background task handle the primary internal failure mode (Nexus process crashes) by resolving unfinished records and marking them Unknown after a 4-hour timeout. This occurs automatically without customer notification.

Oxide does not alert customers when audit records are approaching the 90-day deletion window or when internal audit processing anomalies are detected. Real-time alerting on audit processing failures for customer export pipelines is the customer’s responsibility.

Oxide Remarks:

Oxide handles internal audit processing failures automatically and silently. The customer is responsible for implementing real-time alerting on their audit log export pipeline: detecting when records fail to be retrieved, when the pipeline stalls, or when the gap between the last exported record and the current time approaches the 90-day deletion threshold.

References:

NIST Control Statement:

Provide and implement the capability to centrally review and analyze audit records from multiple components within the system.

Oxide Description:

Oxide generates structured audit records for all control plane operations in a machine-readable format suitable for ingestion into a centralized SIEM or log management system. Records include the fields required for correlation and investigation: caller identity, source IP, timestamp, resource UUID, operation type, and outcome. The consistent structure across all event types supports automated analysis, cross-event correlation, and reporting within a customer-operated central review platform.

Oxide does not provide a native centralized review, analysis, or reporting capability. Integration with a SIEM and the associated review and response processes are customer responsibilities.

Oxide Remarks:

The customer is responsible for configuring export of the Oxide audit log to their centralized review platform, implementing correlation rules and analysis workflows, and integrating audit review findings into their incident investigation and response processes.

References:

NIST Control Statement:

Provide and implement the capability to process, sort, and search audit records for events of interest based on the following content: [Assignment: organization-defined fields within audit records].

Oxide Description:

Oxide audit records are produced in a structured, machine- readable format suitable for automatic processing. Each record contains consistently typed fields (caller identity, source IP, timestamp, resource UUID, operation type, and outcome) that support filtering, sorting, and aggregation by customer- operated tooling without requiring transformation of the raw log data.

Oxide does not provide native automatic processing of audit records. Selection and processing of events of interest is performed by the customer in their SIEM or log management system after exporting records from the Oxide audit log API.

Oxide Remarks:

Oxide produces structured, machine-readable audit records and exposes them through the audit log API. The customer is responsible for exporting records and performing the selection, sorting, searching, and processing of events of interest in their own SIEM or log management tooling; Oxide does not provide native automatic processing of audit records. Customer-side responsibilities must be documented in the system SSP.

References:

NIST Control Statement:

Store audit records [Assignment: organization-defined frequency] in a repository that is part of a physically different system or system component than the system or component being audited.

Oxide Description:

Oxide stores audit records internally within the rack on the same physical system that generates them. Oxide does not provide a separate physical storage system for audit records. Long-term storage of audit records on a physically separate system is the customer’s responsibility, accomplished by exporting records to customer-operated external storage before the 90-day internal retention window expires.

Oxide Remarks:

The customer is responsible for exporting audit records to a physically separate storage system. The external system must be outside the Oxide rack’s physical boundary to satisfy AU-9(2). Exports should be continuous to ensure records are available on the separate system before Oxide’s internal copies are deleted.

References:

NIST Control Statement:

Implement cryptographic mechanisms to protect the integrity of audit information and audit tools.

Oxide Description:

Oxide does not apply cryptographic integrity protection (such as digital signatures or hash chains) to audit records. The audit log API is TLS-protected, ensuring integrity of records in transit, but no cryptographic proof of record integrity is generated or attached to records at rest.

Audit records are structurally immutable within the system (completed records cannot be modified via any user-facing API), but this immutability is enforced by access control rather than cryptographic means. Organizations requiring cryptographic integrity assurance must apply it to exported records after retrieval.

Oxide Remarks:

Oxide provides transport integrity via TLS and structural immutability via access control. Organizations with a requirement for cryptographic integrity proof of audit records must implement signing or hashing of exported records in their external storage pipeline.

References:

NIST Control Statement:

Compile audit records from [Assignment: organization-defined system components] into a system-wide (logical or physical) audit trail that is time-correlated to within [Assignment: organization-defined level of tolerance for the relationship between time stamps of individual records in the audit trail].

Oxide Description:

Oxide generates a unified, system-wide audit trail. All control plane API operations (regardless of which rack component or resource they affect) are recorded through the single Nexus control plane service into one audit log. There is no per-component log aggregation required; the audit trail is system-wide by design.

All audit records share a consistent timestamp format (RFC 3339 UTC at microsecond resolution) generated from NTP-synchronized system clocks. This ensures time correlation across all records in the trail, with timestamp accuracy bounded by the NTP synchronization tolerance configured during initial rack setup.

References:

NIST Control Statement:

Provide and implement the capability for [Assignment: organization-defined individuals or roles] to change the logging to be performed on [Assignment: organization-defined system components] based on [Assignment: organization-defined selectable event criteria] within [Assignment: organization-defined time thresholds].

Oxide Description:

Oxide does not provide the capability for designated personnel to change which events are logged. Audit record generation is automatic and applies uniformly to all covered control plane API operations; no user or administrator can add or remove event types from the audit log, adjust logging verbosity, or suppress logging for specific operations or components.

This is a deliberate design property (audit coverage cannot be reduced by any actor with access to the system) rather than a planned feature gap.

Oxide Remarks:

The absence of selective logging configuration means AU-12(3) does not apply to this component. SSP authors should document this in their SSP and assess whether their authorization requires dynamic audit adjustment capability. If it does, that capability must be implemented at the SIEM layer on exported records rather than within the Oxide system.

References:

NIST Control Statement:

Initiate session audits automatically at system start-up.

Oxide Description:

Audit record generation begins automatically when the Oxide control plane starts. No manual initialization or administrator action is required to start session auditing. All API operations are captured from the moment the control plane is available, with no window during startup in which events go unrecorded.

References:

NIST Control Statement:

Provide and implement the capability for authorized users to remotely view and hear content related to an established user session in real time.

Oxide Description:

Oxide is an API-driven system; all user session activity consists of API operations, which are fully captured in the audit log. Authorized users with Fleet-level access can remotely view the activity of any session by querying the audit log filtered by the target session’s credential identifier (session token ID or API token ID).

Near-real-time monitoring is possible by continuously polling the audit log API for recent entries associated with a credential identifier. Oxide does not provide a native push-based streaming interface for live session events; real-time viewing requires active polling of the audit log.

Oxide Remarks:

Remote session viewing is accomplished through audit log queries, not a dedicated session monitoring interface. The customer is responsible for implementing any tooling required to continuously poll and present live session activity from the audit log API.

References:

NIST Control Statement:

Ensure risk monitoring is an integral part of the continuous monitoring strategy that includes the following:

Oxide Description:

Oxide provides two data sources that support risk-based monitoring of the system.

The audit log records all control plane changes (IAM policy modifications, resource provisioning and deletion, configuration changes, and authentication events) in structured, exportable records. Ingestion into a SIEM enables customer-defined risk-based alerting on events relevant to the organization’s risk posture.

Oximeter metrics provide continuous infrastructure telemetry that can surface anomalous resource consumption patterns potentially indicative of risk-relevant activity, such as unexpected compute or network utilization.

Oxide does not perform risk monitoring or generate risk-based alerts on the customer’s behalf.

Oxide Remarks:

The customer is responsible for defining which events and conditions are risk-relevant, configuring detection rules in their SIEM against the Oxide audit log, and establishing response procedures for risk-based alerts.

References:

NIST Control Statement:

Oxide Description:

Oxide automatically enforces access restrictions for all system changes and generates audit records of enforcement actions without requiring manual intervention or administrator oversight of individual requests.

References:

NIST Control Statement:

Oxide Description:

Oxide provides API-queryable configuration state that supports periodic review of system capabilities. Current VPC firewall rules, IAM policy assignments, Silo settings, and network configurations can be retrieved at any time via the control plane API, enabling customer-conducted reviews against the documented baseline. The audit log provides a record of all configuration changes since the last review, supporting targeted review of what has changed.

Oxide does not perform periodic reviews or automatically identify unnecessary capabilities. Scheduling reviews, evaluating current configuration against least-functionality requirements, and disabling unneeded functions are customer responsibilities.

Oxide Remarks:

The customer is responsible for establishing a periodic review schedule, querying current configuration state via the API, comparing against the documented least-functionality baseline, and disabling or removing any functions, ports, protocols, or services no longer required.

References:

NIST Control Statement:

Prevent program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies, rules of behavior, and/or access agreements regarding software program usage and restrictions] ; rules authorizing the terms and conditions of software program usage].

Oxide Description:

Oxide prevents unauthorized program execution at the hypervisor and control plane levels.

At the control plane level, RBAC restricts which users can provision and launch compute resources. Users holding only Viewer roles can inspect configuration but cannot create or start instances. This prevents unauthorized users from launching workloads on the system.

At the hypervisor level, bhyve enforces strict isolation between guest VMs and the host system. Guest workloads cannot execute code at host OS or hypervisor privilege levels, regardless of what runs inside the VM.

Oxide does not control which programs execute within guest VM operating system environments. Prevention of unauthorized software execution inside guest VMs (application whitelisting, execution policies, and similar controls) is the responsibility of the tenant operating the VM.

Oxide Remarks:

Oxide prevents unauthorized instance provisioning via RBAC and prevents guest escape via hypervisor isolation. The customer is responsible for controlling program execution within their guest VMs using guest OS mechanisms such as application allowlisting, mandatory access control, or execution prevention policies.

References:

NIST Control Statement:

Oxide Description:

Oxide enforces an authorized-software-only execution environment on its control plane and firmware components. The Oxide control plane (Omicron) runs exclusively Oxide-authored services (Nexus, sled agent, Crucible, OPTE, and MGS) with no extraneous daemons or execution paths. The host OS (Helios) boots only through phbl from the host boot image installed by the TUF-verified update process; RoT and service processor firmware are likewise installed only through that process, and RoT firmware must additionally carry a valid signature to execute. Oxide-authored software components are open source and version-controlled, and the set of Oxide-authored software running on any sled is deterministic and auditable from source.

Software execution within guest VMs is outside Oxide’s control plane boundary. The customer determines what operating systems and applications run inside their VMs.

Oxide Remarks:

Oxide implements CM-7(5) for its own control plane and firmware software set. The customer is responsible for implementing authorized software controls within their guest VMs using guest OS mechanisms such as application allowlisting, mandatory access control (SELinux, AppArmor), or execution prevention policies enforced by the guest operating system.

References:

NIST Control Statement:

Implement multi-factor authentication for access to privileged accounts.

Oxide Description:

Multi-factor authentication for privileged account access is supported through two mechanisms depending on the authentication path.

For Silos configured with SAML 2.0 federated authentication, MFA is enforced at the customer’s external identity provider before the SAML assertion is issued to Oxide. Oxide honors the IdP’s authentication decision; customers can require MFA for all users, including privileged accounts (Silo Administrators), at the IdP.

Oxide’s own privileged access via the technician port uses SSH public keys stored exclusively on YubiKey hardware security keys. YubiKey PIN entry is required before the key can be used, making technician port authentication effectively two-factor: possession of the hardware token plus knowledge of the PIN.

Silos using the local Silo identity provider (username/password) do not currently support a second authentication factor at the Oxide layer.

Oxide Remarks:

For SAML-authenticated Silos, the customer must configure MFA enforcement at their identity provider for all privileged accounts (Silo Administrators and Fleet Administrators). Silos using the local identity provider cannot currently satisfy MFA requirements for privileged accounts at the Oxide layer; customers with this requirement should configure SAML federation with an MFA- capable identity provider.

References:

NIST Control Statement:

Implement multi-factor authentication for access to non-privileged accounts.

Oxide Description:

Multi-factor authentication for non-privileged account access is supported through SAML 2.0 federated authentication. For Silos configured with a SAML identity provider, MFA is enforced at the customer’s external identity provider before the SAML assertion is issued to Oxide. Customers can require MFA for all users, including non-privileged accounts (Project Collaborators, Limited Collaborators, and Viewers), at the IdP.

Silos using the local Silo identity provider (username/password) do not currently support a second authentication factor at the Oxide layer.

Oxide Remarks:

For SAML-authenticated Silos, the customer must configure MFA enforcement at their identity provider for all users, including non-privileged accounts. Silos using the local identity provider cannot currently satisfy MFA requirements at the Oxide layer; customers with this requirement should configure SAML federation with an MFA-capable identity provider.

References:

NIST Control Statement:

When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.

Oxide Description:

Oxide requires individual authentication for all control plane access. The system has no group authenticators and no shared accounts. Every user is issued a unique identity within their Silo and authenticates with their own credentials: username/password for local IdP or a SAML assertion bound to their individual IdP identity. API access tokens and web console sessions are issued per-user and cannot be shared across identities. Because no group authenticator mechanism exists, the precondition for IA-2(5) cannot arise.

References:

NIST Control Statement:

Implement multi-factor authentication for [Selection (one or more): local; network; remote] access to [Selection (one or more): privileged accounts; non-privileged accounts] such that:

Oxide Description:

Oxide satisfies the separate-device requirement through two authentication paths.

For Oxide’s own privileged access via the technician port, authentication uses SSH public keys stored exclusively on YubiKey hardware security keys held by Oxide support personnel. The YubiKey is a discrete hardware token physically separate from the Oxide rack being accessed. PIN entry is required before the key can be used, providing two factors (token possession and PIN knowledge) with the authenticator on a device other than the system being accessed.

For Silos configured with SAML 2.0 federated authentication, the authentication exchange is mediated by the customer’s external identity provider. When the customer configures MFA at their IdP, the second factor (hardware token, authenticator app, or push notification) is on the user’s own device, which is separate from the Oxide system being accessed. The SAML assertion delivered to Oxide is the result of an authentication event that occurred on infrastructure and devices outside the Oxide rack.

Silos using the local Silo identity provider (username/password) do not support a second authentication factor and do not provide a separate-device authenticator.

Oxide Remarks:

The separate-device requirement is satisfied for technician port access (Oxide-operated) and for SAML-federated users when the customer enforces MFA at their identity provider. The customer is responsible for configuring MFA at the IdP and ensuring the authenticator mechanism used meets the separate-device requirement. Silos using the local identity provider cannot satisfy IA-2(6); customers with this requirement must configure SAML federation with an MFA-capable identity provider.

References:

NIST Control Statement:

Implement replay-resistant authentication mechanisms for access to [Selection (one or more): privileged accounts; non-privileged accounts].

Oxide Description:

Oxide implements replay-resistant authentication through a combination of transport-layer protection and protocol-level controls, with one known gap.

All API and web console authentication traffic is carried over TLS 1.2 or 1.3. TLS uses ephemeral session keys and nonces, preventing an attacker from replaying captured authentication exchanges at the transport layer.

Privileged shell access over the technician port authenticates via SSH with YubiKey-backed public keys. SSH challenge-response authentication is inherently replay-resistant: each authentication exchange uses a unique challenge, and the private key never leaves the hardware token.

For Silos using SAML 2.0 federated authentication, SAML assertions are time-bounded but Oxide does not currently track previously consumed assertion IDs. A captured, unexpired SAML assertion could be replayed within its validity window. Tracking assertion IDs to close this gap is tracked in omicron#7820.

Oxide Remarks:

The SAML assertion replay gap (omicron#7820) is a known limitation. Customers relying on SAML authentication for privileged accounts should be aware that assertion-level replay resistance is not currently enforced by Oxide and should configure short assertion validity windows at their identity provider as a compensating measure.

References:

NIST Control Statement:

Accept and electronically verify Personal Identity Verification-compliant credentials.

Oxide Description:

Oxide does not natively accept or electronically verify PIV credentials at the control plane. For Silos configured with SAML 2.0 federated authentication, PIV-based authentication can be achieved by federating with an identity provider that accepts PIV smart card credentials and issues a SAML assertion to Oxide upon successful verification. In this configuration, PIV credential acceptance and verification occur at the customer’s identity provider; Oxide trusts the resulting SAML assertion and maps it to a Silo user identity.

Oxide Remarks:

PIV credential acceptance is not implemented at the Oxide layer. To satisfy IA-2(12), the customer must configure Silo SAML federation with an identity provider that accepts PIV credentials and enforces PIV authentication for the relevant user population. Silos using the local identity provider cannot satisfy this control.

References:

NIST Control Statement:

Authenticate [Assignment: organization-defined devices and/or types of devices] before establishing [Selection (one or more): local; remote; network] connection using bidirectional authentication that is cryptographically based.

Oxide Description:

Oxide implements cryptographic bidirectional device authentication for rack hardware through the sprockets protocol. Sprockets uses mutual TLS 1.3 with PKI rooted in each sled’s Hardware RoT. The session keys used in every sprockets connection are certified by the sled’s PlatformId keypair on each boot; because the PlatformId private key is derived from a PUF-based UDS and never leaves the RoT, session authentication is hardware-bound. Every sled verifies the certificate and remote attestation of the other before exchanging trust quorum shares, making authentication bidirectional: neither sled trusts the other without cryptographic proof of identity and an authentic, RoT-signed report of firmware measurements that matches the reference values.

For VM instances, bidirectional authentication with external services is enabled by the key binding mechanism in the VM attestation API. The VM instance generates an ephemeral key pair and includes the public key in the qualifying_data of its attestation request. The resulting attestation cryptographically binds the instance’s identity (boot disk digest, UUID) to its public key, rooted in the Oxide platform identity PKI. An external service that verifies this attestation can establish an authenticated channel with the instance knowing that the key is held by a cryptographically verified VM on the rack.

For external API clients, Oxide presents a TLS server certificate on all control plane connections, allowing clients to authenticate the server. Client-side device authentication via mutual TLS (mTLS), where the server cryptographically authenticates the connecting device, is planned but not yet implemented.

Oxide Remarks:

Cryptographic bidirectional device authentication for external API clients is planned via mTLS but not yet available. Until mTLS is implemented, customers requiring bidirectional device authentication for API clients must enforce this through network-level controls outside the Oxide system boundary.

References:

NIST Control Statement:

For password-based authentication:

Oxide Description:

Oxide implements password-based authentication for local Silo identity provider accounts. Passwords are transmitted exclusively over TLS 1.2 or 1.3, stored using the Argon2 key derivation function, and never logged or stored in plaintext. Silo Administrators configure minimum password length and can reset any user’s password via the API. Checking new passwords against a list of commonly-used or compromised passwords is planned but not yet implemented (omicron#2307). This control applies only to local Silo IdP accounts; password management for SAML-authenticated Silos is handled entirely by the customer’s identity provider.

Oxide Remarks:

Compromised password list checking (smt.a, smt.b) is planned but not yet implemented. Until available, customers using local Silo IdP authentication should enforce strong password selection through administrative policy. Customers requiring periodic password rotation must manage this manually through administrative password resets, as Oxide does not enforce rotation automatically. SAML-authenticated Silos should enforce all password requirements at their identity provider.

References:

NIST Control Statement:

Oxide Description:

Oxide uses public key-based authentication in two contexts: SAML assertion signature verification and technician port SSH access.

For SAML-authenticated Silos, Oxide verifies each incoming SAML assertion’s cryptographic signature against the X.509 certificate supplied in the Silo’s SAML metadata configuration. The certificate establishes the trust anchor; assertions that cannot be verified against it are rejected. The authenticated IdP identity is mapped to the corresponding Silo user record. Private key material for assertion signing is held exclusively by the customer’s identity provider and never transmitted to Oxide.

For the technician port, Oxide pre-registers SSH public keys in Omicron. The corresponding private keys are generated and stored on YubiKey hardware security tokens held by Oxide support personnel. Private keys are hardware-bound and cannot be exported from the device. Each YubiKey is assigned to one individual at a time and protected by a PIN; PINs are rotated by administrators when keys are reassigned. The authenticated SSH identity maps to Oxide support access, not to a customer-managed account.

Oxide Remarks:

For SAML-authenticated Silos, the customer is responsible for managing the IdP’s signing certificate lifecycle, including certificate rotation, and updating the Silo’s SAML metadata configuration when certificates change. Customers should ensure their IdP signing key is stored in a hardware security module or equivalent protected storage.

References:

NIST Control Statement:

Prohibit the use of cached authenticators after [Assignment: organization-defined time period].

Oxide Description:

Oxide does not support cached authenticators. All authentication is performed live against the control plane; there is no offline or locally-cached credential path. API access tokens and web console session cookies are active credentials verified on every request against the running control plane; they are not cached copies of credentials that could be used independently of a live connection. Because no caching mechanism exists, the use of cached authenticators is structurally prohibited.

NIST Control Statement:

Accept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.

Oxide Description:

Oxide does not natively accept or verify PIV credentials at the control plane. For Silos configured with SAML 2.0 federated authentication, PIV-based authentication can be achieved by federating with an identity provider that accepts PIV smart card credentials and issues a SAML assertion to Oxide upon successful verification. PIV credential acceptance and verification occur at the customer’s identity provider; Oxide trusts the resulting SAML assertion and maps it to a Silo user identity. This path supports acceptance of PIV credentials issued by other agencies when those credentials are accepted by the configured IdP.

Oxide Remarks:

To satisfy IA-8(1), the customer must configure Silo SAML federation with an identity provider that accepts PIV credentials from other agencies and enforces PIV authentication for the relevant user population. Silos using the local identity provider cannot satisfy this control.

References:

NIST Control Statement:

Oxide Description:

Oxide supports SAML 2.0 as its external authenticator mechanism. Each Silo can be configured with one external SAML identity provider; Oxide validates incoming assertions cryptographically against the certificate configured in the Silo’s SAML metadata before accepting the authentication. Oxide accepts only assertions that pass this validation; unauthenticated or signature- invalid assertions are rejected.

Whether a configured IdP meets NIST SP 800-63 assurance level requirements is outside Oxide’s enforcement boundary. Oxide does not evaluate or certify the compliance posture of configured identity providers.

Oxide Remarks:

The customer is responsible for verifying that their configured SAML identity provider meets applicable NIST SP 800-63 assurance level requirements and documenting the accepted external authenticator in their SSP. Oxide enforces cryptographic validity of assertions but does not enforce IdP compliance posture.

References:

NIST Control Statement:

Conform to the following profiles for identity management [Assignment: organization-defined identity management profiles].

Oxide Description:

Oxide supports SAML 2.0 federation, which can carry identity assurance attributes from the customer’s identity provider to Oxide. When a Silo is configured for SAML authentication, the assurance level at which users authenticate is determined by the identity provider’s configuration. Oxide trusts the SAML assertion issued by the configured IdP and maps the authenticated identity to a Silo user; it does not independently enforce a specific NIST SP 800-63 Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), or Federation Assurance Level (FAL).

Conformance to specific identity management profiles (e.g., NIST SP 800-63 IAL2/AAL2) requires that the customer’s identity provider be configured and operated at the required assurance level.

Oxide Remarks:

The customer is responsible for configuring their SAML identity provider to operate at the identity management profile required by their authorization (e.g., NIST SP 800-63 IAL2/AAL2 for moderate or high assurance systems). Oxide’s SAML integration provides the federation mechanism; assurance level enforcement occurs at the identity provider.

References:

NIST Control Statement:

Cryptographic keys that protect access tokens are generated, managed, and protected from disclosure and misuse.

Oxide Description:

Oxide-issued access tokens are random bearer tokens rather than signed tokens; there are no Oxide-held cryptographic keys used to sign or encrypt access tokens. Confidentiality and integrity of tokens in transit is provided by TLS 1.2 or 1.3 on the control plane API and web console (see SC-23). Web console session identifiers are 160-bit cryptographically random values transmitted only in secure cookies. Access tokens and session state stored in the control plane database are protected at rest by ZFS dataset encryption with keys derived from the rack secret managed by the trust quorum (see SC-28). For SAML-based authentication, Oxide verifies assertions against the IdP-supplied signing certificate stored in the Silo’s SAML configuration; the corresponding private signing key remains exclusively at the customer’s identity provider and is never held by Oxide.

Oxide Remarks:

The customer is responsible for generating, protecting, and managing the SAML signing keys at their identity provider, and for rotating the IdP signing certificate at Oxide as needed to reflect IdP key rotation. The customer should document IdP key management practices in their SSP.

References:

NIST Control Statement:

The source and integrity of identity assertions and access tokens are verified before granting access to system and information resources.

Oxide Description:

Oxide verifies the source and integrity of every identity assertion and access token before granting access. For SAML-federated authentication, Oxide validates the cryptographic signature on each incoming SAML assertion against the IdP signing certificate configured for the Silo, and checks each SAML response against the XML signature rules in section 5.4 of the SAML core specification (same-document signature references only, and only the transforms the specification permits), rejecting responses with any other signature structure; assertions with invalid signatures, mismatched issuers, or signing certificates not matching the configured IdP are rejected and do not result in a user session. For Oxide-issued access tokens (API bearer tokens and web console session cookies), every request to the control plane carries the token, and the control plane resolves the token against the server-side session and token store on each request before authorization is evaluated; tokens that are missing, expired, revoked, or not recognized result in the request being rejected. Token lookups occur over TLS, so neither the token value nor the verification result transits the network in plaintext.

References:

NIST Control Statement:

In accordance with [Assignment: organization-defined identification and authentication policy], assertions and access tokens are:

Oxide Description:

Oxide manages access tokens and session identifiers across their lifecycle as follows. Generation: tokens are cryptographically random values (160-bit for web console session identifiers) generated by the control plane. Issuance: tokens are issued by the control plane only after successful authentication of the user via local credentials or a verified SAML assertion. Refresh: tokens are renewed via re-authentication; a token that has reached its configured maximum validity is invalidated and the user must authenticate again to obtain a new token. Revocation: Silo Administrators can immediately invalidate all active sessions and tokens for any user via the user_logout API; users can delete their own API access tokens via the API. Time restriction: web console sessions enforce an eight-hour idle timeout and a twenty-four-hour absolute timeout; the maximum API access token validity period is configurable by the Silo Administrator via the auth_settings_update API. Audience restriction: tokens and session identifiers are scoped to the Silo in which they were issued; a token issued in one Silo does not authorize access to another Silo’s resources, and per-API authorization decisions further constrain the token to the role-based privileges of the issuing user.

Oxide Remarks:

The customer is responsible for setting and documenting the organization-defined policy that governs the API token maximum validity period (via auth_settings_update) and the operational practices for periodic session revocation. Web console idle and absolute timeouts are not currently customer-configurable; operator- configurable values are planned (omicron#5477).

References:

NIST Control Statement:

Limit the number of external network connections to the system.

Oxide Description:

Oxide limits management access to a single consolidated external access point: the control plane API, served over TLS on a defined endpoint per Silo. All rack management operations (provisioning, configuration, user management, and monitoring) are performed through this single interface. There is no secondary management interface exposed externally. The physical technician port is a local out-of-band interface, not an external network connection; it carries an SSH path reserved for Oxide support personnel and a proxy to the same control plane API, which a fleet administrator can use from a host plugged into the port to recover from a misconfigured allow-list.

External network connections for customer workloads are determined by VPC configuration. Each VPC can be connected to external networks through Internet Gateways or other routing constructs; the number and scope of these external connections is determined by the customer’s network topology design and VPC firewall configuration.

The number of physical external connections from the rack to the customer’s network infrastructure is determined by the customer’s facility and network design, which is outside Oxide’s control.

Oxide Remarks:

The customer is responsible for limiting external network connections to workloads through VPC firewall rules and routing configuration, and for controlling the number and scope of physical network connections between the Oxide rack and external networks in the customer- controlled facility.

References:

NIST Control Statement:

Deny network communications traffic by default and allow network communications traffic by exception [Selection (one or more): at managed interfaces; for [Assignment: organization-defined systems] ].

Oxide Description:

Oxide provides a stateful firewall on every virtual network interface, enforced by OPTE at the hypervisor layer before traffic reaches the guest VM. Firewall rules are configured per VPC and applied to all interfaces within that VPC. Because enforcement occurs below the guest, guests cannot bypass or modify the firewall rules applied to their own interfaces.

New VPCs are created with a minimal default ruleset. The default ruleset is not a strict deny-all configuration; it is designed to permit basic connectivity to minimize initial setup friction. Customers must replace or augment the default rules with an explicit deny-by-default policy to satisfy SC-7(5)'s requirement that traffic be denied by default and permitted only by exception.

Oxide Remarks:

The customer is responsible for configuring VPC firewall rules to implement a deny-by-default, allow-by-exception policy. The default VPC ruleset does not satisfy this requirement without modification. Customers should remove or restrict permissive default rules and define explicit allow rules for required traffic flows only.

References:

NIST Control Statement:

Prevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using [Assignment: organization-defined safeguards].

Oxide Description:

SC-7(7) applies to two distinct contexts in the Oxide deployment model.

For remote users and administrators connecting to the Oxide control plane API, the split tunneling behavior of their client devices and VPN configurations is outside Oxide’s control. Oxide does not manage or enforce routing policies on the devices used to access the control plane. Whether a remote administrator’s workstation uses split tunneling is determined by the customer’s remote access infrastructure.

For guest VM network traffic, Oxide’s VPC subnet routing is fully configurable. Customers can configure VPC routing tables to require that all guest traffic (including traffic destined for external networks) routes through a centralized egress point (such as an inspection or monitoring appliance), preventing guest workloads from establishing direct external connections that bypass security controls.

Oxide Remarks:

The customer is responsible for preventing split tunneling on remote devices used to access the Oxide control plane, through their remote access policy and VPN configuration. For guest workloads, the customer must configure VPC routing to route all traffic through managed egress points if split tunneling prevention is required for guest network traffic.

References:

NIST Control Statement:

Route [Assignment: organization-defined internal communications traffic] to [Assignment: organization-defined external networks] through authenticated proxy servers at managed interfaces.

Oxide Description:

Oxide provides configurable VPC routing that supports routing guest VM traffic through customer-deployed proxy servers before it reaches external networks. Customers can define custom routes in VPC routing tables that direct outbound traffic to a specific next-hop address (such as a proxy or inspection appliance running in the VPC) rather than routing it directly to an external gateway. OPTE enforces the configured routes at the hypervisor layer; guest VMs cannot bypass routing policy by manipulating their own network stack.

Oxide does not provide a built-in authenticated proxy service. The proxy server, its authentication configuration, and the policy governing which traffic must traverse it are the customer’s responsibility.

Oxide Remarks: