Security & trust
Built to earn trust, not just claim it
Security teams don't take virtualization vendors at their word, and Basalt isn't built to ask them to. Every access control, audit record, and cryptographic function described here exists in the platform today — implemented at the architecture level, not bolted on as an afterthought or promised for a future release. Where Basalt's security posture is still maturing toward formal government certification, we say so plainly, because a security product that overstates its own assurance is a liability, not a feature.
Access Control & Governance
Basalt enforces least-privilege administration through role-based access control, with a set of preset roles that separate distinct administrative functions — security policy, storage administration, network administration, day-to-day operations, and read-only visibility — instead of collapsing them into one all-powerful administrator account. That separation means the person who can view a system isn't automatically the person who can change it, and the person who manages network policy doesn't inherit the ability to manage storage or security settings.
For organizations running multiple programs, tenants, or business units on shared infrastructure, Basalt adds a second layer of isolation underneath the role model: row-level security enforced at the database itself, so one tenant's records, configurations, and resources are structurally invisible to another. Multiple programs can share the same underlying platform without a security team having to trust an application-layer promise that data stays separated — the isolation is enforced where the data lives. Platform administration is itself walled off from tenant infrastructure by the same policy, so operating the platform doesn't imply visibility into every tenant running on it.
Auditability
Every consequential action in Basalt — who did it, what they did, which resource it touched, where it came from, and exactly when — is written to an access-controlled, append-only audit record. Basalt tracks hundreds of distinct action types across the platform, which means the audit trail isn't a thin log of logins and logouts; it's a detailed, queryable history of administrative and operational activity across the environment.
That level of detail matters in two very different moments: during routine security reviews, where an organization needs to demonstrate operational discipline without reconstructing events from memory, and during incident response, where the ability to answer "who did what, and when" quickly and definitively is the difference between a contained event and a prolonged investigation. Because audit logging runs locally on every node, a site that's been operating disconnected from central management still produces a complete record that reconciles once connectivity is restored — nothing about being offline creates a gap in accountability.
Encryption & Cryptography
Communication between Basalt agents and the control plane is encrypted, and authentication and agent identity rely on signed credentials rather than static, reusable secrets. Underlying this, Basalt incorporates FIPS-enabled cryptographic capabilities as part of its security architecture — a foundation that matters for organizations whose own policies or governing frameworks require cryptographic modules to meet that standard.
Session handling follows the same disciplined posture: sessions are validated centrally so they can be revoked instantly if needed, and credentials are never stored or handled in ways that would undermine the protections cryptography is supposed to provide. Security here isn't a single control — it's layered, from how a node proves its identity when it first joins the platform through how every subsequent action it takes is authenticated and protected in transit.
Hardened by Design
Basalt's underlying host layer is built to be hardenable, with configuration baselines designed to align with recognized security hardening standards used widely across government and regulated environments — including the kind of session timeout discipline, account lockout behavior, and configuration controls that those standards call for. This is a deliberate architectural choice made from the beginning of the platform's design, not a retrofit applied in response to a compliance deadline.
Being designed to align with a recognized hardening standard is different from holding a published, product-specific implementation guide issued by a certifying authority — and we're careful not to blur that distinction. What Basalt provides today is a platform built from the ground up to make that kind of formal hardening and certification process achievable, with the underlying control mapping and configuration discipline already in place as a starting point rather than a gap to be closed later.
Supply Chain Transparency
Basalt is implemented primarily in Rust, a memory-safe systems language that structurally eliminates entire categories of memory-corruption vulnerabilities — the class of bug responsible for a large share of the most serious hypervisor security disclosures across the industry. That protection exists by construction, not because of a policy someone has to remember to enforce.
That foundation is reinforced by disciplined software supply chain practices. Every Basalt release ships with a software bill of materials — a complete, machine-readable inventory of the components inside the product, generated with standard, industry-recognized tooling — so customers and their security teams don't have to take Basalt's composition on faith. Dependencies are vetted and locked into a controlled build process ahead of time rather than pulled from the open internet at build time, which closes off a common compromise vector and, as a side benefit, lets Basalt be built entirely disconnected from the internet — a meaningful property for organizations that need to validate and deploy software in air-gapped or tightly controlled environments. This sits inside a broader program to track the origin and ongoing maintenance of the platform's lowest-level components, consistent with recognized supply-chain risk management practices used across government and industry.
Ongoing Certification Journey
Triq is actively pursuing formal security evaluation for Basalt appropriate to government and regulated environments, including work toward an independent NIAP evaluation against the relevant server virtualization protection profile. This work is in progress, not complete, and we describe it that way deliberately: Basalt does not currently hold a completed NIAP evaluation, an authority to operate, a DISA-published product-specific hardening guide, an Impact Level 5 or 6 authorization, or a completed cross-domain solution certification. We're not aware of a technical or architectural obstacle to pursuing any of these, and Basalt's control mapping, audit depth, and supply-chain evidence are built to support that process — but formal authorization is always granted by the relevant government or enterprise authorizing body, on that body's process and timeline, not by Basalt or by Triq.
The Standard We Hold Ourselves To
Security-conscious buyers have learned to be skeptical of vendors who lead with certification logos and follow with caveats in the fine print. Basalt takes the opposite approach: strong access control, deep auditability, encrypted communications, memory-safe foundations, and supply chain transparency are built into the platform today, verifiable by any security team that wants to look closely — and every claim about where formal certification stands is stated in exactly the terms that are true, no more and no less. That's the standard we hold ourselves to, because in government and regulated markets, credibility is the only kind of trust that actually scales.
Bring your security team
We work directly with customers and their security teams to support the evidence and control mapping that accreditation processes require. Tell us what your review looks like and we'll bring the engineers who can answer it.