Comparison

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.

  • Updated August 26, 2026
  • 7 min read
Ref
C-01
Kind
Definition

What Manual RMF is.

Manual RMF is how most authorization packages are actually produced: a Word SSP, a control tracker in Excel, scan exports in a folder, STIG checklists on a share drive, a POA&M spreadsheet, and one or two people who hold the whole picture. It is not a product and nobody chose it — it is what happens by default when the work is real and the tooling budget is not. It gets systems authorized, and it has been getting systems authorized for two decades.

CertiField is an operational RMF layer. It holds one authorization record per system and generates the SSP, SAR, POA&M, OSCAL output and authorization package from it.

Ref
C-02
Kind
Fit
Stated
August 26, 2026

Which one fits the problem you have.

Which tool fits depends on the shape of your program — how often the system changes, who owns the authorization, and what your submission path already is.

When Manual RMF is the right answer

  • The system is frozen. No meaningful change since the last authorization and none planned.
  • The boundary is genuinely small — a handful of components, one assessor, a package one person holds comfortably.
  • Your ATO expires in six weeks. Do not introduce tooling into the middle of a submission.
  • There is no budget, which is a real constraint and not a failure of judgment.

When CertiField is the right answer

  • The same reconciliation happens every cycle and nobody can find last cycle's reasoning.
  • One person holds the model of how everything connects, and that is your largest single risk.
  • The same false positives are re-adjudicated every scan cycle.
  • Reassessment scope cannot be computed, so the safe default is reassessing everything — and that default is why system changes get deferred.

Using both

Not applicable in the usual sense, but the transition matters. The right moment to move is straight after an authorization, when the record is as accurate as it will ever be and nothing is on fire — not during a submission.

Ref
C-03
Kind
Detail

Manual RMF is not a failure of competence

Worth starting here, because vendor content on this topic is often contemptuous about the alternative and the contempt is unearned.

Manual RMF gets systems authorized. The people doing it are usually competent and usually under-resourced, and the spreadsheet is not evidence of poor judgment — it is evidence that nobody funded anything better and the ATO was due.

If you are running manual RMF and it is working, you do not have an emergency. What you may have is a cost nobody has put on a budget.

Where the cost actually sits

The expensive part is not the initial package. Building the first one is hard, but it is a bounded project with a deadline and usually a budget, and teams get through it.

The expensive part is every change afterwards.

A component moves to a different trust zone. A new STIG release drops. A dependency picks up a critical CVE. An implementation changes because engineering found a better way. Each forces the same four questions:

  1. What actually changed?
  2. Which controls does it affect?
  3. What has to be reassessed?
  4. Which documentation is now stale?

In a manual process all four are answered by a person, from memory, under time pressure. The answer is not written down as a decision — it exists as edits scattered across a Word file, a tracker and a POA&M sheet — so the next person to ask starts over.

That is the compounding cost. Not the hours. The fact that the reasoning is never retained, so it is paid for again every single time.

The three characteristic strains

Useful to name because they have different fixes.

Drift. The document and the system disagree, and nobody knows by how much. Survivable for a long time, and then not, usually during an assessment.

Key-person concentration. One person knows why AC-17 was tailored, which scan the POA&M item came from, and why the false positive in row 340 is a false positive. That knowledge does not transfer, because it was never anywhere but in them.

Rebuild-on-change. Because reassessment scope cannot be computed, the safe option is to reassess everything. That is expensive, and it is why so many teams treat a significant system change as a reason to delay the change.

The last one is the one worth caring about most, because it quietly makes security the reason engineering stops improving the system. Nobody designs that outcome and the process produces it anyway.

What a tool fixes, and what it does not

It fixes: the reconciliation, the traceability, the regeneration, the re-deciding of settled questions, the loss of reasoning when a person leaves, and the inability to compute what a change affects.

It does not fix: an unclear boundary, an absent categorization rationale, an engineering team that will not tell you what shipped, an AO with unstated expectations, or a program that has not decided who owns the ATO. Those are organizational, and software makes them more visible rather than less.

If your problem is the second list, buying software produces a well-instrumented version of the same problem, on a subscription. That is worth knowing before rather than after.

When to stay manual

There are cases where staying manual is the correct call, and a vendor who cannot name them is not being straight with you.

  • The system is frozen. The delta engine has nothing to compute.
  • The boundary is genuinely tiny. One assessor, a package one person holds comfortably.
  • The ATO expires in six weeks. Ship the package, then fix the process while nothing is on fire.

The move is usually worth making right after an authorization — when the record is as accurate as it will ever be, and there is time to bring it forward properly.

Ref
C-04
Kind
Evaluation
Ask
every vendor, us included

Ask for the demonstration, not the claim.

The most reliable way to compare tools is to make each vendor show you the same things in a live product. Ask us these too — if we cannot do one of them, that is worth knowing before you buy.

  1. 01 Where is the rationale for the last tailoring decision we made? Ask this of your own process first. If the answer is a person rather than a place, that is the exposure, and it is the one that does not survive a staffing change.
  2. 02 Which assessment result is current, and what system state was it made against? On a manual process this is usually answerable only by the person who made it, and only if they remember.
  3. 03 Which of the findings in this scan did we already dismiss, and why? If nothing retains the adjudication, this work is repeated in full every cycle.
Ref
C-05
Kind
Sources

Sources.

The description of Manual RMF above is drawn from its vendor's or owner's own public material and from government issuances, as of August 26, 2026.

If we have described Manual RMF inaccurately, tell us and we will correct it. Email info@certifield.software with the correction and the public source, and the change and its date will appear here.

Ref
C-06
Kind
Other comparisons

Other comparisons.

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.

Next step

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