Resources
What we have learned keeping authorization packages current.
Written for practitioners, by people doing the work. No gated PDFs, no lead-capture wall, and no article that turns out to be a product page wearing a hat.
- Ref
- R-00
- Kind
- Concepts
- Start here
- four definitions
Start with the four terms.
Most of what follows depends on these. They are precise where the market's vocabulary is not, and each one is a claim we are willing to be held to.
Operational RMF
The continuous work of keeping an authorization true, as distinct from the project of producing a package.
The authorization record
The structured facts that constitute an authorization. The SSP, SAR and POA&M are renderings of it.
Evidence-grounded generation
Every statement in an artifact traces to a fact, and every fact to the evidence behind it.
Reassess the delta
Derive reassessment scope from a computed architecture diff instead of rebuilding the package.
- Ref
- R-01
- Kind
- Index
- 01 What is RMF automation, and what is it actually automating? 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.
- 02 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.
- 03 RMF automation tools, compared by category 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.
- 04 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.
- 05 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.
- 06 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.
- 07 Automating SSP generation without losing the thread 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.
- 08 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.
- 09 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.
- 10 Automating SAR generation from the assessment record 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.
- 11 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.
- 12 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.
- 13 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.
- 14 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.
- 15 Evidence reuse in RMF, and why most programs cannot do it 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.
- 16 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.
- 17 Scan results to POA&M, without losing the thread 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.
- 18 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.
- 19 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.
- 20 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.
- 21 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.
- 22 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.
- 23 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.
- 24 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.
- 25 AI in RMF: what should and shouldn't be automated 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.
- 26 STIG applicability without the 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.
- 27 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.
- 28 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.
- 29 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.
- Ref
- R-02
- Kind
- Comparisons
- Method
- category and fit
Comparisons.
Category and fit rather than a feature scorecard — what each system is, when it is the right answer, and how it works alongside CertiField. Several of these are systems CertiField exports to rather than competes with, and the pages say so.
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
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
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
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
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
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.
- Ref
- R-03
- Kind
- Topics
Topic guides.
Shorter pages answering the questions people arrive with, rather than the ones we would rather they asked.
eMASS alternative
Why most teams looking for one do not actually want one.
STIG checklist management
CKL and CKLB at scale, without losing work on every release.
Nessus / ACAS to POA&M
Scan results into correlated, exportable POA&M items.
RMF for contractors
RMF when nobody on the team does RMF full time.
CMMC and STIG overlap
What genuinely reuses between them, and what does not.
Next step