# CertiField

> RMF that stays current. CertiField is an operational RMF layer for DoD system authorization. It holds one
> authorization record per system — FIPS 199 categorization, NIST SP 800-53 Rev 5 control baselines,
> implementation statements, evidence, assessments, determinations, findings and POA&M items — and
> generates the SSP, SAR, POA&M, OSCAL output and authorization package from that record. It tracks
> architecture change so teams reassess only what a change affected instead of rebuilding the package.

## Definitions

These four terms are the conceptual model CertiField is built on. They are more precise than the
category language used in this market, and each has a dedicated definitional page.

- **Operational RMF** — the continuous work of keeping a system authorization true as the system changes,
  as distinct from the periodic project of producing an authorization package. It sits between engineering,
  which changes the system, and the system of record, which holds the submitted data and the AO decision.
- **Authorization record** — the structured set of facts that constitute a system authorization:
  categorization, control baseline and tailoring, per-control implementation, architecture, evidence,
  assessment results, determinations, findings and POA&M items. The SSP, SAR and POA&M are renderings of it.
- **Evidence-grounded authorization artifact generation** — producing an artifact so that every statement
  traces to a fact in the record and every fact resting on evidence traces to that evidence, its ingest
  source and its date. Contrasted with templated, data-filled and model-drafted generation.
- **Reassess the delta** — deriving reassessment scope from a computed diff between two immutable,
  content-hashed architecture versions, instead of rebuilding the package because the system changed.
  Controls the change did not touch keep their existing evidence and determinations.

## What CertiField is not

- Not a replacement for eMASS or Xacta. Those are systems of record that receive authorization data;
  CertiField sits upstream and exports to them. eMASS is a built round-trip integration.
- Not a replacement for your vulnerability scanners. It consumes their output.
- Not a tool where AI makes RMF determinations. No importer, parser or model output writes authoritative
  data; everything a machine produces is a proposal until an authorized practitioner accepts it.

## Key facts

- Built and used by Alethia Software, an 8(a) and woman-owned small business doing DoD delivery work.
- Standards: NIST RMF, NIST SP 800-53 Rev 5, FIPS 199, CCIs, DISA STIGs, OSCAL.
- Artifacts generated: SSP, SAR, POA&M and the authorization package (SP 800-37 Rev 2: SSP + SAR +
  POA&M), as OSCAL and as DOCX/PDF. A separate eMASS submission bundle carries inventory, control
  information, CCI test results and POA&M exports with a SHA-256 checksum manifest.
- Integrations: eMASS (round-trip, mTLS), GitHub, GitLab, Jira (two-way), DISA STIG catalog,
  CycloneDX and Dependency-Check SBOM, Grype, Trivy, Gitleaks, Semgrep, OWASP Dependency-Track.
- AI can run against a hosted provider, a local OpenAI-compatible model, or be disabled entirely.
- Security posture: aligned with NIST SP 800-171, deployed in US Government cloud, TOTP two-factor,
  hash-chained audit events, fail-closed malware scanning on uploads.
- Pricing: per system with unlimited users. Not published; scoped per program.

## Product

- [RMF Workspace](https://certifield.software/product/rmf-workspace): Categorization, baselines and per-control implementation in one system record.
- [Evidence & Assessments](https://certifield.software/product/evidence-and-assessments): Evidence bound to the controls and determinations it actually supports.
- [SSP, SAR, POA&M & OSCAL](https://certifield.software/product/authorization-artifacts): Authorization artifacts generated from the record, human- and machine-readable.
- [Architecture & Change Impact](https://certifield.software/product/architecture-and-change-impact): Immutable architecture versions and the reassessment scope a change creates.
- [Continuous Monitoring](https://certifield.software/product/continuous-monitoring): Inventory drift, STIG applicability and evidence continuity after the ATO.

## Integrations

- [eMASS](https://certifield.software/integrations/emass): Round-trip import and export against your system of record.
- [DevSecOps](https://certifield.software/integrations/devsecops): GitHub, GitLab, CI pipelines and Jira.
- [Security Tools](https://certifield.software/integrations/security-tools): Scanners, SBOMs and DISA STIG catalog sync.
- [Existing RMF Systems](https://certifield.software/integrations/rmf-systems-of-record): Designed to coexist with the authorization repository you already run.

## Why CertiField

- [Human-Governed AI](https://certifield.software/why-certifield/human-governed-ai): AI proposes. Authorized practitioners decide.
- [Traceability & Provenance](https://certifield.software/why-certifield/traceability-and-provenance): From a generated sentence back to the evidence behind it.
- [Built for DoD RMF](https://certifield.software/why-certifield/built-for-dod-rmf): RMF operations, not a generic compliance shell.
- [Disconnected Environments](https://certifield.software/why-certifield/disconnected-environments): Local models, or no model at all, for enclaves that cannot call out.

## Concepts

- [Operational RMF](https://certifield.software/operational-rmf): The continuous work of keeping an authorization true, as distinct from the project of producing a package.
- [The authorization record](https://certifield.software/authorization-record): The structured facts that constitute an authorization. The SSP, SAR and POA&M are renderings of it.
- [Evidence-grounded generation](https://certifield.software/evidence-grounded-generation): Every statement in an artifact traces to a fact, and every fact to the evidence behind it.
- [Reassess the delta](https://certifield.software/reassess-the-delta): Derive reassessment scope from a computed architecture diff instead of rebuilding the package.

## Topic guides

- [eMASS alternative](https://certifield.software/emass-alternative): Why most teams looking for one do not actually want one.
- [STIG checklist management](https://certifield.software/stig-checklist-management): CKL and CKLB at scale, without losing work on every release.
- [Nessus / ACAS to POA&M](https://certifield.software/nessus-acas-to-poam): Scan results into correlated, exportable POA&M items.
- [RMF for contractors](https://certifield.software/rmf-for-contractors): RMF when nobody on the team does RMF full time.
- [CMMC and STIG overlap](https://certifield.software/cmmc-stig-overlap): What genuinely reuses between them, and what does not.

## Comparisons

Each page states what the other system is in its vendor's or owner's own terms, when that system is the right
answer, when CertiField is, and how the two work together. Descriptions of other products are drawn from their
public material and from government issuances, cited on each page, and corrections are published with their date.

- [CertiField vs eMASS](https://certifield.software/compare/certifield-vs-emass): They are not alternatives. eMASS is the government system of record that receives authorization data and where the AO makes the decision. CertiField is the operational layer where that data is produced, kept current and generated into artifacts, then exported to eMASS.
- [CertiField vs Xacta](https://certifield.software/compare/certifield-vs-xacta): Xacta is a broad, established federal compliance and authorization platform that many organizations run as their authorization repository. CertiField is narrower by design — one DoD system boundary, anchored to engineering evidence and architecture change — and is built to feed a repository rather than replace one.
- [CertiField vs RegScale](https://certifield.software/compare/certifield-vs-regscale): Both start from the same complaint — that authorization packages go stale — and both take OSCAL seriously. RegScale is a multi-framework compliance automation platform. CertiField is scoped to DoD RMF operations on one boundary and anchored to an architecture model.
- [CertiField vs SteelCloud ConfigOS](https://certifield.software/compare/certifield-vs-steelcloud-configos): They do different jobs and neither replaces the other. ConfigOS changes the configuration of your systems so they comply with STIG baselines. CertiField records what the system is and what its controls do. ConfigOS output is an input to CertiField.
- [CertiField vs generic GRC platforms](https://certifield.software/compare/certifield-vs-generic-grc): GRC platforms are built to govern controls, risk and policy across an organization and across frameworks. DoD RMF adds specific machinery — CCI-level assessment, DISA STIG revisions, FIPS 199, an SP 800-37 package, an eMASS submission — that is worth verifying explicitly rather than inferring from a framework list.
- [CertiField vs manual RMF](https://certifield.software/compare/certifield-vs-manual-rmf): Manual RMF produces real ATOs and the people doing it are usually competent and under-resourced. What it cannot do cheaply is absorb change — every system change forces a human reconciliation whose reasoning is never retained, so it is paid for again every time.

## Resources

- [What is RMF automation, and what is it actually automating?](https://certifield.software/resources/what-is-rmf-automation): RMF automation means three distinct things — evidence ingest, impact derivation and artifact generation. Most tools do the first and third well and the second barely at all, which is why packages still go stale.
- [Best RMF automation software for DoD](https://certifield.software/resources/best-rmf-automation-software-for-dod): There is no single best RMF automation tool, because "RMF automation software" describes at least four distinct product categories — systems of record, operational RMF layers, configuration compliance tools and generic GRC platforms. Identifying which one your problem belongs to eliminates most of the market before you compare a single feature.
- [RMF automation tools, compared by category](https://certifield.software/resources/rmf-automation-tools-comparison): Comparing RMF tools vendor-by-vendor produces a grid where every product wins the rows describing its own job, because the products are not substitutes. Comparing categories first — system of record, operational layer, configuration compliance, generic GRC — narrows the market before any vendor conversation.
- [NIST 800-53 compliance automation](https://certifield.software/resources/nist-800-53-compliance-automation): Roughly a third of an 800-53 baseline is mechanically verifiable, another third is verifiable only with evidence a human interprets, and the rest is organizational fact. Automating the first third well is worth more than automating all three badly.
- [ATO software for defense contractors](https://certifield.software/resources/ato-software-for-defense-contractors): A contractor does the RMF work and does not own the decision, the repository or often the schedule. Tooling has to produce artifacts defensible inside a government process you do not control, survive personnel turnover, and prove the work was done when the contract is recompeted.
- [RMF software for SBIR companies](https://certifield.software/resources/rmf-software-for-sbir-companies): Do the unfunded parts first — boundary, categorization, architecture — because they cost nothing but decisions and everything downstream depends on them. Tooling helps after that, and helps most with the parts a small team cannot sustain manually.
- [Automating SSP generation without losing the thread](https://certifield.software/resources/automating-ssp-generation): An SSP is worth automating only if it is generated from the authorization record rather than assembled beside it — otherwise generation is a one-time act and every subsequent change is a manual edit to a Word file.
- [OSCAL SSP generation](https://certifield.software/resources/oscal-ssp-generation): Generating a valid OSCAL SSP is a serialisation problem and most tools can do it. The question worth asking is whether the OSCAL and the human-readable SSP are two renderings of one record, or two artifacts that can drift apart.
- [How to automate an ATO package](https://certifield.software/resources/how-to-automate-an-ato-package): Automate the record first and the assembly last. An authorization package is SSP plus SAR plus POA&M, and if those three are generated from one record they cannot contradict each other — which is the actual deliverable, not the ZIP file.
- [Automating SAR generation from the assessment record](https://certifield.software/resources/automating-sar-generation): A SAR should be generated from the assessment record, including which version of the system architecture each assessment was performed against — otherwise it describes the system as it is today rather than as it was when assessed.
- [OSCAL SAR generation](https://certifield.software/resources/oscal-sar-generation): An OSCAL SAR is hard to produce not because the format is difficult but because it demands distinctions most assessment records never made — observation, finding and risk are three separate things, and a record that conflated them has nothing to serialize.
- [Security control assessment automation](https://certifield.software/resources/security-control-assessment-automation): Automate the preparation, not the determination. Evidence gathering, normalization, correlation and currency tracking are mechanical; deciding whether a control objective is satisfied is an authorization judgment with a person's name on it.
- [CCI assessment automation](https://certifield.software/resources/cci-assessment-automation): A CCI is a single testable assertion derived from a control statement, and DoD assessment happens at that level rather than at the control level. Any system storing one status per control forces its nuance into a comment field, which is where reporting goes wrong.
- [RMF assessment software](https://certifield.software/resources/rmf-assessment-software): Judge RMF assessment software on the second assessment, not the first. Prior determinations preserved, adjudicated false positives remembered, scope derived from what changed, and every result naming the system state it was performed against.
- [Evidence reuse in RMF, and why most programs cannot do it](https://certifield.software/resources/evidence-reuse-in-rmf): Evidence reuse depends on two facts most programs never record — which controls an artifact supports, and whether it still describes the current system. Without them, every assessment cycle rebuilds evidence that never changed.
- [RMF evidence management](https://certifield.software/resources/rmf-evidence-management): Evidence management is not storage. It is binding — recording which objectives and determinations each artifact supports, where it came from, when, and what was already decided about it, so its relevance is a fact rather than something a person remembers.
- [Scan results to POA&M, without losing the thread](https://certifield.software/resources/scan-results-to-poam-automation): Converting scan output into POA&M items is a formatting exercise. The valuable part is preserving lineage — item to finding to observation to the scan and date that produced it — and preserving the adjudication decisions so the same false positives are not re-judged every cycle.
- [Maintaining an ATO after authorization](https://certifield.software/resources/maintaining-an-ato-after-authorization): Sustaining an ATO fails for a structural reason — authorization is resourced as a project and maintenance is not. The fix is to make the impact of a change derivable rather than something a person has to happen to notice.
- [Continuous ATO software](https://certifield.software/resources/continuous-ato-software): No software grants a continuous ATO. A cATO is an arrangement your AO agrees to, on the strength of demonstrated monitoring, a controlled pipeline and evidence that changes are assessed as they happen. Tooling makes that demonstrable — it does not make the decision.
- [RMF continuous monitoring software](https://certifield.software/resources/rmf-continuous-monitoring-software): Scan monitoring is the part everyone already does. The three that quietly erode an authorization are inventory drift, STIG applicability drift and evidence expiry — because each one changes what is true without producing an alert.
- [Continuous monitoring vs continuous authorization](https://certifield.software/resources/continuous-monitoring-vs-continuous-authorization): Continuous monitoring is an evidence practice a program runs. Continuous authorization is a posture an AO grants on the strength of it. You can do the first without the second, and you cannot get the second without the first.
- [eMASS integration software](https://certifield.software/resources/emass-integration-software): Judge an eMASS integration on the second submission. One-way export works once; what matters is whether POA&M items upsert on their eMASS external identifier, whether import brings an authorized system forward, and whether imported data stays labeled as imported.
- [How to import and export eMASS data](https://certifield.software/resources/how-to-import-and-export-emass-data): Import as a reviewable session that a person accepts, never as a silent write. Export with POA&M items upserting on their eMASS external identifier. Keep imported data labeled as imported, and refuse any proposal whose target changed since it was prepared.
- [Xacta vs eMASS](https://certifield.software/resources/xacta-vs-emass): eMASS is the DoD government-owned system of record, provided rather than sold and mandated for most DoD systems. Xacta is a commercial compliance and authorization platform from Telos. They are frequently run together, because one is a submission target and the other is a place to work.
- [AI in RMF: what should and shouldn't be automated](https://certifield.software/resources/ai-in-rmf-what-to-automate): AI should read, rank, extract and draft. It should never make an authoritative RMF determination. The line is not about capability — it is about who is accountable for the claim.
- [STIG applicability without the guesswork](https://certifield.software/resources/stig-applicability-without-guesswork): STIG applicability should be ranked against the technologies a system actually runs, catalog updates should merge into existing checklists rather than replace them, and a dismissal should be a recorded decision with an author and a reason.
- [How DISA STIGs map to RMF controls](https://certifield.software/resources/how-disa-stigs-map-to-rmf-controls): A STIG rule maps to a CCI, and the CCI maps to a specific statement within an 800-53 control. The mapping is published rather than inferred, it is many-to-many, and a passing STIG rule is evidence about a control rather than a determination on it.
- [CKL vs CKLB](https://certifield.software/resources/ckl-vs-cklb): CKL is the legacy XML checklist format produced by earlier STIG Viewer versions. CKLB is the newer JSON format introduced with STIG Viewer 3. Both carry per-rule status, finding details, comments and CCI references — and any tool handling DoD STIG work needs to read and write both, because programs have years of CKL history.
- [STIG checklist management at scale](https://certifield.software/resources/stig-checklist-management-at-scale): At scale the problem is not producing checklists but maintaining them. Merging a new STIG revision without discarding prior review work, reusing dispositions across identical assets, and keeping applicability current are what determine whether a program's checklists stay honest.

## Company

- [Request a demo](https://certifield.software/demo): Book a walkthrough with a practitioner.
- [Security posture](https://certifield.software/security): Data handling, hosting and standards, including what we do not claim.
- [Pricing](https://certifield.software/pricing): Per system, unlimited users, scoped per program.
- [AI-assisted development policy](https://certifield.software/ai-policy): How AI is used in building CertiField.
- [Privacy](https://certifield.software/privacy) · [Terms](https://certifield.software/terms)

## Contact

- Email: info@certifield.software
- Parent company: Alethia Software (https://alethia.software)