Operational RMF for DoD systems

RMF that stays current.

Turn system evidence into assessment-ready controls, findings, POA&Ms, SSPs, SARs and authorization packages — without rebuilding your RMF package every time the system changes.

CertiField connects engineering reality to the RMF record, so security teams can assess what changed, reuse what hasn't, and keep every authorization artifact grounded in current evidence.

system / authorization boundary published 19 AUG 2026 · 14:02Z
v6 sha256:4c1e…8ab2
v7 sha256:9f3a…d071
changed
4 components · 1 connection · 1 data flow
reassess
  • AC-4
  • SC-7
  • SC-8
  • CA-3
  • CA-9
  • SC-13
controls in scope of the change
preserved
289 controls unchanged — evidence, determinations and assessment history retained

Assessments stay bound to the architecture version they were performed against. Publishing a new version never moves that binding.

  • NIST RMF
  • NIST SP 800-53 Rev 5
  • FIPS 199
  • OSCAL
  • DISA STIGs
  • eMASS
  • DevSecOps
Ref
R-01
Kind
Problem
Applies to
system authorization boundary

Your ATO shouldn't go stale the moment the system changes.

Most RMF processes still run on disconnected spreadsheets, Word documents, scan exports, evidence folders and manual interpretation. Then a vulnerability changes. A component moves. A new STIG applies. An implementation changes. New evidence arrives.

And somebody has to work out, by hand, four questions that nobody has time to answer properly:

  • What changed?
  • Which controls does it affect?
  • What has to be reassessed?
  • Which documentation is now stale?

Change the system. Understand the RMF impact. Update what matters.

CertiField connects those pieces into one authorization workflow, so the answer to all four is a query against the record rather than a week of reconciliation.

System reality

What engineering actually produces

  • Architecture
  • Inventory
  • DISA STIGs
  • Scan results
  • SBOMs
  • CI/CD pipelines
  • Evidence

CertiField

The operational RMF layer

  • Controls
  • Evidence
  • Assessments
  • Determinations
  • Findings
  • POA&M

Authorization

What reviewers and systems receive

  • SSP
  • SAR
  • POA&M
  • Authorization package
  • OSCAL
  • eMASS
Ref
R-02
Kind
Output
Formats
DOCX · PDF · OSCAL · eMASS
Ref
R-03
Kind
Differentiator
Mechanism
immutable architecture versions
Binding
assessment → version

Don't regenerate the whole package. Reassess the delta.

CertiField keeps every published architecture version immutable and content-hashed, computes what actually changed between two of them, and works out the reassessment scope that change creates. What "reassess the delta" means →

Changed architecture?

See the affected controls and the assessment scope that comes with them, derived from the diff rather than declared by hand.

New evidence?

Connect it to the controls and determinations it supports, so its relevance is recorded rather than remembered.

New findings?

Carry them through assessment into POA&M with the link back to the scan, the checklist item or the control that produced them.

Unchanged controls?

Keep the evidence, determinations and authorization context you already built. Nothing is discarded because something else moved.

Stop reconstructing the authorization story every time the system changes.

CertiField's Architecture Change Impact report comparing published version 27 to the current working set. It reports 8 changes, 18 affected controls and a highest impact of High, with a table listing each change, the object it touched, its category and the controls related to it.
Comparing two architecture snapshots: 8 changes, 18 controls that may warrant review across 11 control families, and the specific controls each change touches. The report never alters a control, an assessment or a package. Architecture · RMF Impact
Ref
R-04
Kind
Differentiator
Rule
no machine writes a fact
Audit
hash-chained events

Every answer has a source.

AI can assist the RMF process. It should not become the authority. CertiField keeps machine recommendations and authoritative RMF decisions structurally separate.

From a generated sentence back to the evidence that supports it.

Ref
R-05
Kind
Position
Master switch
AI can be disabled
Providers
hosted · local · none

AI assists. Your people decide.

CertiField uses AI where it genuinely reduces practitioner workload: extracting information from documents you already have, identifying relationships, ranking STIG applicability, drafting content and surfacing potential impacts.

It does not quietly turn that output into an RMF determination. Model-invented control, CCI and STIG identifiers are discarded server-side before anyone sees them, and user content is fenced off from instructions on the way into the model.

  1. AI proposes.
  2. Evidence supports.
  3. Authorized practitioners decide.
  4. CertiField preserves the record.

Cloud-connected or disconnected.

Run AI through a hosted provider, through a local OpenAI-compatible model such as Ollama or LM Studio, or switch it off entirely for environments where external inference is not appropriate. With AI disabled, STIG applicability still arrives with relevance profiles carried in the offline catalog bundle — an enclave does not have to choose between isolation and useful applicability data.

How CertiField runs disconnected →
Ref
R-07
Kind
Ecosystem
eMASS
round-trip import/export

Keep your systems of record. Make them easier to feed.

CertiField is the operational layer between the systems that produce security evidence and the systems that receive authorization data. It is not trying to replace either end.

Where CertiField sits between engineering tools and government authorization repositories
UpstreamCertiFieldDownstream
GitHub · GitLab Evidence bound to controls eMASS — round-trip import and export
Jira Per-control implementation and assessment OSCAL — SSP, SAR and POA&M
Scanners · SBOM · CI Findings, determinations and POA&M Xacta and other required repositories — designed to coexist
DISA STIG catalog Authorization artifacts on demand Reviewer-ready DOCX and PDF

CertiField is designed to coexist with the authorization repository your program already runs. eMASS is a built integration; other repositories are supported through the package export.

Ref
R-08
Kind
Model

One authorization record, from categorization through continuous monitoring.

CertiField is not a document generator with an RMF workflow bolted on. The authorization record is the product, and the documents are what it emits.

  1. Categorize

    FIPS 199 impact levels, the high-water mark, and the system narratives that describe what is being authorized.

  2. Select

    NIST SP 800-53 Rev 5 baselines seeded from the NIST OSCAL catalog, tailored into a per-system control set.

  3. Implement

    Implementation statements, evidence, STIG applicability and the engineering data behind each control.

  4. Assess

    Assessment procedures, per-CCI results, determinations and findings, each bound to what it was assessed against.

  5. Authorize

    SSP, SAR, POA&M and the authorization package, generated from the record rather than assembled beside it.

  6. Monitor

    Architecture change, inventory drift, evidence continuity and the reassessment scope each of them creates.

Ref
R-10
Kind
Entry points

Two ways in, depending on where your program already is.

Already authorized

Bring the existing authorization forward instead of starting over.

Import your current state from eMASS — control information, CCI test results, POA&M items and inventory — and keep it current from there. CertiField is often worth more after the ATO than during it.

How CertiField sustains an ATO

Building a package

Turn system facts, evidence and assessments into the artifacts your reviewers need.

Categorize, select a baseline, capture implementation and evidence, run the assessment, and generate the SSP, SAR, POA&M and package from what you built rather than from a template.

How CertiField builds an ATO

Next step

See what your RMF process looks like when the package keeps up with the system.