Public brief / Assurance / Rev 2026.08

Government evaluation path

A component validation, a product evaluation, a system assessment, and an Authorizing Official’s decision apply to different boundaries. Black Swan Net treats those boundaries as mission requirements—not marketing synonyms.

Status: active developmentAudience: AOs, ISSMs, ISSOs, SCAs, integrators, mission ownersReading time: 7 minutes

Direct answer

How does government evaluate Black Swan Net?

A government customer evaluates a defined Black Swan Net configuration inside a defined system boundary. The customer maps controls and overlays, reviews evidence, tests the deployment, and assesses residual risk. Its AO makes the authorization decision through RMF or the applicable governance process.

Black Swan Net organizes the evidence for that process: architecture, trust assumptions, data flows, SBOMs, provenance, test results, configuration baselines, operating procedures, records controls, and continuous-assurance data.

The program uses the terms federal security teams already know. Its working vocabulary includes RMF, ATO, SCA, SSP, POA&M, FIPS 140-3, NIAP/Common Criteria, CSfC, CNSA, STIG/SRG, SBOM, SSDF, CONOPS, COMSEC, CUI, and NSS. These terms identify work products and constraints. They do not claim that Black Swan Net holds any approval or authorization.

Mission segmentation

Three profiles. Three different claim sets.

ProfileMission scopeEvaluation directionCurrent status
Commercial privacyExecutive, legal, investigation, crisis-response, and high-assurance enterprise use.Independent mobile, protocol, cryptographic, supply-chain, and penetration review.Active product development and design-partner engagement; no operational deployment claimed.
Regulated / CUIFederal contractors, critical infrastructure, regulated enterprise, and customer-defined unclassified missions.Customer-scoped NIST SP 800-171 and/or SP 800-53 mapping, cryptographic-module boundary planning, configuration controls, assessment, and ATO support where applicable.Design-partner path open; no CUI authorization claimed.
Classified / NSSA separate configuration and operating model for a sponsor-defined national-security mission.Government sponsor; applicable NIAP/Common Criteria, CNSA, CSfC or other directed path; RMF assessment and exact deployment authorization.Not approved or authorized; requires sponsorship and a defined architecture.

CUI is not a product badge

CUI protection obligations attach to the information, contractual and regulatory environment, organizational system, and applicable requirements. A product can contribute controls and evidence, but it does not independently authorize every customer’s CUI use case.

Classified/NSS is a separate program

The classified/NSS profile is a separate program. It requires a government sponsor, exact mission and data types, approved components, the required cryptographic architecture, evaluation evidence, operating constraints, and customer authorization. The commercial or CUI profile is not a shortcut.

Evaluator-ready record

Security case as a product deliverable

EVIDENCE / 01

System boundary

Architecture, data flows, trust assumptions, dependencies, inherited controls, external services, information types, and residual risk.

EVIDENCE / 02

Build provenance

Component inventory, SBOM, reproducibility strategy, signed releases, update path, supplier evidence, and configuration baseline.

EVIDENCE / 03

Verification record

Protocol analysis, test vectors, code and design review, penetration findings, remediation records, and operational exercises.

EVIDENCE / 04

Mission CONOPS

Provisioning, synchronized session windows, unavailable-peer behavior, custody, loss, revocation, content handling, records, incident response, and recovery.

EVIDENCE / 05

Control implementation

Applicable control narratives, assessment procedures, responsibility matrix, customer dependencies, exceptions, and POA&M inputs.

EVIDENCE / 06

Continuous assurance

Vulnerability intake, change control, release monitoring, reassessment triggers, end-of-support policy, and customer notification.

A useful evidence package answers five questions: What was tested? Which version and configuration? Who tested it? What were the assumptions and findings? What remains outside the evaluated boundary?

Authorization semantics

Four boundaries that must not collapse

BoundaryWhat it establishesWhat it does not establish
Component validationA specific component met a defined validation program and boundary.Validation of the complete Black Swan Net product or deployment.
Product evaluationA specified product/version/configuration was evaluated against stated criteria.Authorization for every agency, mission, network, or information type.
System assessmentControls in an exact deployed system were assessed with inherited and customer controls.The Authorizing Official’s risk-acceptance decision.
Customer authorizationThe designated authority accepted risk for a scoped system and mission under stated conditions.A universal approval or approval of materially changed configurations.
CURRENT CLAIM BOUNDARYBlack Swan Net does not currently claim FIPS validation, NIAP evaluation, CSfC listing or registration, NSA or DISA approval, RMF authorization, CUI approval, or classified authorization.

Primary public references

Frameworks, not endorsements

The following authoritative sources define public terminology and process context. They do not mention, approve, or endorse Black Swan Net.

Design-study channel

Bring the mission boundary.

Request an unclassified/CUI pilot-scoping or integrator discussion. Do not send protected mission information through the public site.

Request evaluation briefing