Defense & intelligence · Moraph software

Nuclear Command & Control (NC3) Assurance Check

Verify that critical systems match their approved baseline, and evidence every check

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

The NC3 Assurance Check runs scheduled, read-only integrity checks on the software and configurations of critical command and communication systems, comparing what is installed with the baseline your approving authority has signed off. It records the results of link health checks drawn from your existing monitoring and test procedures, and turns every difference into a discrepancy that a person investigates and closes. It runs entirely in your environment, under your authority.

The problem it solves

For the most critical systems, operators need confidence that the software and configurations in service are exactly the ones that were approved, and that communication paths are working. In practice, verification often relies on manual checklists, separate tools for each system type, and results recorded in logs and spreadsheets. Differences can go unnoticed between inspections, and assembling evidence for an inspection or authorization review takes weeks of effort.

  • Integrity and configuration checks are manual, periodic and inconsistent across system types
  • Approved baselines live in documents rather than in something a check can compare against
  • Link health results are scattered across monitoring tools and test logs
  • Evidence for inspections and authorization reviews is assembled by hand

Who uses it

  • System owners and operations centers responsible for critical command and communication systems
  • Configuration managers who maintain approved baselines
  • Information system security managers and officers
  • Authorizing officials and approving authorities who sign off baselines
  • Inspectors and auditors who review integrity and configuration evidence

Requirements it supports

DoD Instruction 8510.01, Risk Management Framework for DoD SystemsDoD Instruction 8500.01, CybersecurityNIST SP 800-53 Rev. 5, configuration management and system and information integrity controlsCNSSI No. 1253, Security Categorization and Control Selection for National Security SystemsNIST SP 800-128, Guide for Security-Focused Configuration Management of Information SystemsDISA Security Technical Implementation Guides (STIGs)

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    Assurance status

    Operators see every system and path in scope with its latest result, and unverified is shown as plainly as a failure.

    SystemSiteSoftwareConfigurationLast checkResult
    System A-01Example Site 1MatchesMatches06:00Verified
    System A-02Example Site 1Matches2 differences06:00Discrepancy open
    System B-01Example Site 2Not readNot read06:00Unverified
    System C-04Example Site 3MatchesMatches06:00Verified
    Operators see every system and path in scope with its latest result, and unverified is shown as plainly as a failure.

  2. Step 2

    A discrepancy

    Each difference shows what was expected, what was found and whether an authorized change explains it.

    DR-0712 · System A-02 · Configuration

    Baseline
    System type A, version 14 (approved)
    Setting
    Logging destination
    Expected
    Example collector 2
    Found
    Not set
    Linked change
    None found
    Assigned to
    Cybersecurity analyst

    Other differences in this check

    • Session timeout differs from baseline; explained by change CH-3381
    • No software or file hash differences
    Each difference shows what was expected, what was found and whether an authorized change explains it.

  3. Step 3

    Investigation and closure

    The discrepancy is investigated, its cause recorded and its closure approved by someone else.

    DR-0712 · System A-02

    1. Difference detected by scheduled checkAssurance Check
    2. Discrepancy opened and assignedAssurance operator
    3. Maintenance log reviewed; setting cleared during a component swapCybersecurity analyst
    4. Cause recorded: error during maintenanceCybersecurity analyst
    5. Setting restored through change CH-3394Configuration manager
    6. Recheck verified; closure approvedISSM
    The discrepancy is investigated, its cause recorded and its closure approved by someone else.

  4. Step 4

    A baseline change

    A new baseline is prepared, verified and approved by three different people before checks use it.

    System type A · Baseline version 15

    1. Prepared from approved build after change CH-3401Configuration manager 1
    2. Software list and hashes verified against build recordConfiguration manager 2
    3. Configuration settings verifiedConfiguration manager 2
    4. Baseline approvedISSM
    5. Version 15 in use for checks on System type AAssurance Check
    A new baseline is prepared, verified and approved by three different people before checks use it.

  5. Step 5

    Link health

    Monitoring status and operator test results for each path are recorded together, and missed tests are flagged.

    PathMonitoring statusLast testTest resultWithin interval
    Path 1UpTodayPassYes
    Path 2UpTodayPassYes
    Path 3DegradedYesterdayPassYes
    Path 4Up8 days agoPassNo
    Monitoring status and operator test results for each path are recorded together, and missed tests are flagged.

  6. Step 6

    The evidence package

    For an inspection, the ISSM assembles baselines, results and closures for the scope and period requested.

    Evidence package · Example Site 1 · Fictional review period

    Systems in scope
    12
    Baselines
    3 system types, all approved
    Scheduled checks
    1,080 run
    Unverified results
    14, all followed up
    Discrepancies
    9 opened, 9 closed
    Result signatures
    All valid

    Contents

    • Baseline register with preparers, verifiers and approvers
    • Check history and link test results
    • Discrepancy records with causes and closures
    • Audit trail extract for the period
    For an inspection, the ISSM assembles baselines, results and closures for the scope and period requested.

Workflows

The principal workflows

  1. Baseline

    Configuration managers record the approved software and configuration baseline for each system, and the approving authority signs it off under two-person control before checks use it.

    • Configuration manager imports software inventories, file hashes and configuration settings from a known-good system or build
    • Each item is tied to the approved configuration documentation
    • A second configuration manager verifies the proposed baseline
    • Approving authority signs off the baseline
    • The signed baseline becomes the reference for all checks on that system

  2. Check

    Collectors read software, file and configuration state from each system on a schedule or on demand, without changing anything, and compare it with the signed baseline.

    • Checks run on the schedule your procedures set, or on demand before a critical activity
    • Read-only collectors gather software versions, file hashes and settings
    • Results compared with the signed baseline and applicable STIG settings
    • Systems that cannot be reached are reported as unverified, never as passing
    • Results signed and stored with the time and collector used

  3. Link health

    Results from your existing monitoring systems and from operator-run test procedures are brought together so the status of each communication path is recorded in one place.

    • Status feeds received from your network and link monitoring systems
    • Operators record the results of scheduled test procedures
    • Each path shown as verified, degraded, failed or not tested within its interval
    • Failures and missed tests raised as discrepancies
    • History kept for each path

  4. Resolve

    Every difference becomes a discrepancy that is investigated, explained and closed by a person, with the evidence kept.

    • Discrepancy opened with the expected and observed values
    • Analyst investigates and links any authorized change record
    • Cause recorded: authorized change, error, fault or suspected tampering
    • Suspected tampering escalated immediately under your procedures
    • Closure approved by the ISSM or designated authority

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Assurance operator

Operations center technician, watch officer, communications technician

Runs the checks, watches their results and makes sure every difference is raised.

Sees

  • Check status for the systems and paths assigned to their center
  • Link health status and test procedure schedule
  • Open discrepancies and their status

Does

  • Starts on-demand checks before critical activities
  • Records results of operator-run test procedures
  • Opens discrepancies and escalates suspected tampering under your procedures
  • Confirms unreachable systems are followed up
  • Hands over open items at shift change

Cannot

  • Change a baseline
  • Close a discrepancy
  • Change check schedules or collector settings
Approvals
None of their own; the discrepancies they raise go to analysts and the ISSM.
Notified about
Failed or unverified checks, failed link tests, and tests missed within their interval.

Configuration manager

Configuration manager, configuration control board secretariat, systems engineer

Keeps the approved baselines accurate and ties authorized changes to them.

Sees

  • Baselines and their version history
  • Check differences against each baseline
  • Authorized change records

Does

  • Prepares baselines from a known-good system or approved build
  • Verifies baselines prepared by another configuration manager
  • Links authorized change records to the differences they explain
  • Prepares a new baseline version after an approved change

Cannot

  • Approve a baseline
  • Verify a baseline they prepared themselves
  • Close a discrepancy
Approvals
Every baseline they prepare is verified by a second configuration manager and approved by the approving authority.
Notified about
Differences matching an open change, baselines awaiting their verification, and baselines returned with comments.

Cybersecurity analyst

ISSO, cyber defense analyst, incident responder

Works out why a system differs from its baseline and records the cause.

Sees

  • Discrepancies assigned to them with expected and observed values
  • Check history for the systems involved
  • Linked change records

Does

  • Investigates discrepancies and records findings
  • Classifies the cause as authorized change, error, fault or suspected tampering
  • Escalates suspected tampering under your incident procedures
  • Recommends closure with the evidence

Cannot

  • Approve the closure of their own discrepancy
  • Change a baseline
  • Delete check results
Approvals
Closure recommendations are approved by the ISSM or designated authority.
Notified about
Discrepancies assigned to them and closures returned for more work.

ISSM or approving authority

Information system security manager, authorizing official's designated representative, system owner

Owns the assurance results and signs off baselines and closures.

Sees

  • All systems, baselines, results and discrepancies within their authority
  • Unverified systems and overdue tests
  • The full audit trail

Does

  • Approves or returns baselines
  • Approves or returns discrepancy closures
  • Sets check and test intervals
  • Approves evidence packages for inspections and authorization reviews
  • Grants and ends access for inspectors

Cannot

  • Approve a baseline or closure they prepared themselves
  • Edit or delete check results or the audit trail
  • Mark an unverified system as passing
Approvals
Approves baselines, discrepancy closures, intervals and evidence packages.
Notified about
Suspected tampering, baselines and closures awaiting approval, and systems unverified beyond the interval set.

Inspector or auditor (read-only)

Inspector general staff, command cyber readiness inspector, assessor

Reviews assurance evidence without being able to change it.

Sees

  • Baselines, check results, link health history and discrepancies within the granted scope
  • Evidence packages
  • The audit trail

Does

  • Reads and searches records within scope
  • Verifies result signatures
  • Exports evidence they are granted, with each export logged

Cannot

  • Change, approve or delete anything
  • See systems outside the granted scope
  • Keep access after it expires
Approvals
Their access is approved by the ISSM with a scope and an end date.
Notified about
Nothing by default.

System administrator

Application administrator, systems administrator

Keeps the product, its collectors and its users running, without any approval authority.

Sees

  • Users, roles and collector status
  • Check schedules and collector configuration
  • The record of permission changes

Does

  • Adds and removes users or maps them from your identity system
  • Deploys and maintains collectors
  • Applies approved schedule changes
  • Applies approved product updates

Cannot

  • Change a baseline or close a discrepancy
  • Grant themselves an operational or approval role
  • Edit or delete check results or the audit trail
Approvals
Role changes and schedule changes are approved by the ISSM.
Notified about
Collectors not reporting, update availability and access reviews coming due.

Permissions at a glance

ActionOperatorConfig mgrAnalystISSMInspectorAdmin
Run on-demand checksFullFullFullFullNo accessNo access
Record test procedure resultsFullNo accessNo accessView onlyView onlyNo access
Prepare a baselineNo accessFullNo accessView onlyNo accessNo access
Verify a baselineNo accessFullNo accessView onlyNo accessNo access
Approve a baselineNo accessNo accessNo accessApprovesView onlyNo access
Open a discrepancyFullFullFullFullNo accessNo access
Investigate a discrepancyView onlyView onlyOwn work onlyFullView onlyNo access
Close a discrepancyNo accessNo accessNo accessApprovesNo accessNo access
Set check and test intervalsNo accessNo accessNo accessApprovesNo accessFull
Export evidence packagesNo accessNo accessNo accessFullView onlyNo access
View audit trailNo accessNo accessView onlyView onlyView onlyView only
Manage users and collectorsNo accessNo accessNo accessApprovesNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Two-person control is built in: baselines are prepared by one person, verified by another and approved by a third, and nobody closes a discrepancy they investigated.
  • No role can change a recorded check result or mark an unverified system as passing.
  • Roles are configured with you during implementation and can be limited by site, system or operations center, so each team sees only what it is responsible for.
  • Access for inspectors and assessors is temporary, read-only, scoped and dated, and every permission change is recorded in the audit trail.

Features

What it does

Signed baselines

Approved software and configuration baselines held as data, with who prepared, verified and approved each version.

Software integrity checks

Installed software versions and file hashes compared with the approved baseline on every check.

Configuration checks

Settings compared with the approved baseline and with applicable STIG settings, with each difference listed.

Read-only collection

Collectors read state from systems and never change it; the product has no ability to send commands to the systems it checks.

Unverified is not passing

A system that could not be reached or fully read is shown as unverified, so a gap in checking is never mistaken for a pass.

Link health record

Status from your monitoring systems and results of operator test procedures, brought together for each communication path.

Discrepancy management

Every difference tracked from detection to closure, with investigation notes, cause and approval.

Two-person control

Baseline changes and discrepancy closures need a second person, and nobody approves their own work.

Change correlation

Differences linked to authorized change records, so expected changes are explained and unexplained ones stand out.

Pre-activity checks

On-demand checks before an exercise, maintenance window or critical activity, with the result recorded for the record.

Signed results

Check results are digitally signed when recorded, so later alteration can be detected.

Evidence packages

Baselines, check history, discrepancies and closures assembled for an inspection or authorization review.

Integrations

How it connects to your systems

Connects toHowWhat flows
Read-only collectorsCollectors installed in your environment read software inventories, file hashes and settings using accounts with read-only rights that your administrators create.In: software, file and configuration state. Nothing is sent to the systems checked.
Network and link monitoringStatus feeds from the monitoring systems you already operate, received through the interfaces they provide.In: link status and alarms.
Configuration management databaseSystem inventory and authorized change records from your configuration management and change control tools.In: systems, components and approved changes.
STIG and benchmark contentApplicable STIG content imported in standard SCAP formats, so configuration checks can include required settings.In: benchmark content selected by your ISSM.
Security monitoringDiscrepancies and suspected tampering events sent to your security monitoring or incident system.Out: discrepancy events.
Identity and accessStaff sign in through your identity provider with CAC, PIV or your multi-factor policy.In: user identity and group membership for role assignment.
Software bill of materialsComponent lists from Moraph's Software Bill of Materials (SBOM) Watchtower or your own SBOM tool can inform baselines.In: component inventories for baseline preparation.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Staff sign in through your identity provider with CAC, PIV or your multi-factor policy.

Role-based access

What each person sees and does follows their role and their sites; preparing, verifying and approving a baseline are separate.

Append-only audit trail

Every check, view, decision and export is logged with the person and time, and records cannot be edited or deleted.

Encryption and keys

Data is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

Cleared US-person support

Support tickets for defense and intelligence clients are handled only by Moraph staff who are US citizens with active clearances.

Your environment only

Operational use runs in your environment under your authority; Moraph hosting, in the United States region, is limited to unclassified evaluation with fictional data.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

10 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Assurance status

For operations centers, system owners and the ISSM

Each system and path with its latest result: verified, differences found, unverified or not tested within its interval.

Break down by
Site, System type, Result, Time since last verification
Delivered as
Live view
Used for
Knowing at any moment what has and has not been verified.

Unverified and overdue

For operators and the ISSM

Systems that could not be checked and tests not run within their interval, with the reason where known.

Break down by
Site, Reason, Age
Delivered as
Live view; shift handover summary
Used for
Closing gaps in checking before they become findings.

Open discrepancies

For analysts, operators and the ISSM

Every open discrepancy with its system, difference, assignee, cause so far and age.

Break down by
Site, Cause category, Assignee, Age
Delivered as
Live view; CSV export
Used for
Working discrepancies to closure.

Pre-activity check record

For operations centers and the ISSM

On-demand checks run before an activity, with results and any discrepancies raised.

Break down by
Activity, System, Result
Delivered as
On request; PDF export
Used for
Showing that systems were verified before a critical activity.

Configuration

Baseline register

For configuration managers and the ISSM

Every baseline version with who prepared, verified and approved it, and the systems it applies to.

Break down by
System type, Version, Approver, Date
Delivered as
Live view; PDF and CSV export
Used for
Confirming each system is checked against a current, approved baseline.

Differences and changes

For configuration managers and analysts

Differences found by checks, with the authorized change that explains each or a note that none was found.

Break down by
System, Change record, Explained or unexplained
Delivered as
Live view; CSV export
Used for
Separating expected changes from those that need investigation.

STIG compliance

For iSSM and ISSOs

Configuration settings checked against applicable STIG content, with open findings and approved deviations.

Break down by
Benchmark, System, Severity category, Status
Delivered as
Live view; CSV export
Used for
Tracking configuration findings alongside baseline integrity.

Link health

Path history

For operations centers and system owners

Status and test results for each communication path over time, including failures and missed tests.

Break down by
Path, Site, Result, Period
Delivered as
Live view; CSV export
Used for
Seeing recurring problems on a path.

Inspection and authorization

Evidence package

For iSSM, inspectors and assessors

Baselines, check history, link test results, discrepancies and closures for a chosen scope and period, with result signatures.

Break down by
Scope, Period, Control
Delivered as
On request; PDF and CSV export
Used for
Answering inspections and authorization reviews without assembling evidence by hand.

Audit trail extract

For iSSM and inspectors

Who did what and when for a chosen system, baseline, discrepancy or period.

Break down by
Record, User, Action, Date range
Delivered as
On request; CSV and PDF export
Used for
Showing that two-person control and approvals were followed.

Exports, access and evidence

  • All reports are produced in your environment; no results leave it unless you export them.
  • Reports respect each viewer's role and scope, so an operations center sees its own systems and inspectors see only what they have been granted.
  • Reports can be run as of a past date and give the same result each time, and check results carry signatures that can be verified on export.
  • Every report run and export is recorded in the audit trail.
  • Summary and evidence reports export to PDF, and detailed results to CSV for use in your own tools.

Deployment

Where and how it runs

Your environment

Installed in your own environment, including networks operated under your authority, with Moraph providing software and support as you allow.

Disconnected installation

For isolated networks, updates and content are delivered as signed packages for your staff to verify and transfer.

Unclassified evaluation

A Moraph-hosted evaluation environment in the United States region, using fictional systems and data only.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Scoping

We work with your system owners and ISSM to agree which systems, system types and paths are in scope and what each check should cover, in the unclassified terms needed for our work.

Installation in your environment

The product and collectors are installed in your environment by your staff or by cleared Moraph staff under your authority.

Collector accounts and access

Your administrators create read-only accounts for collectors, and we confirm that collectors can read what each check needs and nothing more.

Baselines

Your configuration managers prepare the first baselines from known-good systems or approved builds, and they are verified and approved through the product.

Parallel checking

Automated checks run alongside your current manual procedures for a period you choose, and the results are compared before you rely on them.

Authorization support and training

We provide control mapping and evidence for your Risk Management Framework assessment, and train operators, analysts, configuration managers and approvers.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • It verifies; it does not control. It cannot send commands to, reconfigure or repair the systems it checks.
  • No check can prove a system is uncompromised. The product compares systems with their approved baseline and records what it finds; a baseline that is itself wrong will not be detected.
  • It checks only what its collectors are permitted to read. Components without a readable interface must be verified by your own procedures, and their results recorded.
  • Link health depends on your existing monitoring systems and test procedures; the product records their results and does not test links itself.
  • Moraph does not claim accreditation or an authorization to operate for the product. Moraph maps controls and supports your own assessment and authorization.
  • Operation on classified networks takes place in your environment, under your authority and accreditation. Moraph does not hold your operational data.
  • Decisions about discrepancies, escalation and response belong to your personnel and procedures.
  • Remediation is out of scope; differences are fixed through your own change and maintenance processes.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Run the unclassified evaluation environment against fictional systems and introduce a deliberate configuration difference
  2. Make a fictional system unreachable and confirm it shows as unverified, not passing
  3. Walk a baseline through preparation, verification and approval with three people
  4. Investigate and close a discrepancy and review the record it leaves
  5. Assemble an evidence package and check the result signatures
  6. Review the control mapping against your authorization requirements

Questions

Frequently asked questions

Can the product change the systems it checks?

No. Collectors use read-only access and the product has no way to send commands to, reconfigure or repair the systems it checks.

Does a clean result mean a system is uncompromised?

It means the system matched its approved baseline for everything the check could read at that time. It is one part of assurance alongside your other controls and procedures.

Where does it run?

In your environment, under your authority. Moraph hosts only an unclassified evaluation environment with fictional data.

Who at Moraph can support us?

Support tickets for defense and intelligence clients are handled only by Moraph staff who are US citizens with active clearances, and any work in your environment happens under your authority and rules.

Is the product accredited?

Moraph does not claim accreditation for the product. We provide control mapping and evidence to support your own assessment and authorization.

Can we check system types the product does not know yet?

Yes, where the system offers a readable interface. New system types are added by configuring collectors and preparing baselines with your configuration managers.

Next steps

Evaluate Nuclear Command & Control (NC3) Assurance Check

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Nuclear Command & Control (NC3) Assurance Check guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Nuclear Command & Control (NC3) Assurance Check support guide.

Related products