Why CertiField · Built for DoD RMF
RMF operations, in RMF vocabulary.
Generic compliance platforms map DoD RMF onto a framework abstraction and lose the parts that matter: CCIs, STIG applicability, authorization boundaries, the eMASS round trip, and the difference between an ISSO's field and an assessor's.
- NIST RMF
- FIPS 199
- 800-53 Rev 5
- CCIs
- DISA STIGs
- eMASS
- Ref
- W-31
- Kind
- Vocabulary
The nouns are the product.
You can tell how well a tool understands this domain by whether it has a word for the things practitioners argue about.
| Concept | How CertiField holds it |
|---|---|
| Authorization boundary | A first-class system with its own RMF state, not a tag on a project |
| FIPS 199 categorization | C, I and A captured separately; overall impact derived as the high-water mark |
| Control baseline | Low, Moderate and High from the NIST OSCAL catalog, tailored per system |
| CCI | Per-CCI test results attached to the control, not flattened into it |
| DISA STIG | Catalog sync, applicability ranking, checklist merge and recorded dismissals |
| Inheritance | Carried as imported metadata, labeled as such, never as a native determination |
| Interconnection | A CA-3 and SA-9 record with agreements and expiry, distinct from a connection |
| POA&M | Keyed on the external identifier so the eMASS round trip is safe |
- Ref
- W-32
- Kind
- Roles
- Templates
- 11 built-in roles
Roles named after the jobs that exist.
System Owner, ISSO, ISSM, ISSE, Security Control Assessor, Cyber Engineer, Developer, Project Owner, Project Manager, Auditor, Organization Administrator. Not "Admin, Editor, Viewer" with a mapping document taped to the side.
More importantly, the separations those roles imply are enforced at field level rather than at screen level. An assessor recording a determination cannot quietly rewrite the implementation statement they are assessing. That is the separation the process assumes, and most tooling leaves it to good manners.
- Ref
- W-33
- Kind
- Lifecycle
Every step a program actually operates.
-
Categorize
FIPS 199 impact levels, the high-water mark, and the system narratives that describe what is being authorized.
-
Select
NIST SP 800-53 Rev 5 baselines seeded from the NIST OSCAL catalog, tailored into a per-system control set.
-
Implement
Implementation statements, evidence, STIG applicability and the engineering data behind each control.
-
Assess
Assessment procedures, per-CCI results, determinations and findings, each bound to what it was assessed against.
-
Authorize
SSP, SAR, POA&M and the authorization package, generated from the record rather than assembled beside it.
-
Monitor
Architecture change, inventory drift, evidence continuity and the reassessment scope each of them creates.
- Ref
- W-34
- Kind
- Origin
- Built by
- Alethia Software
Built by the people who had to keep the packages current.
CertiField came out of DoD delivery work at Alethia Software — an 8(a) and woman-owned small business — where the same problem kept recurring: the system shipped, the package went stale, and somebody spent a quarter reconstructing an authorization story that had been true six months earlier.
We are not describing a market we researched. We are describing the work we were doing, and the tool we needed to stop doing it by hand.
What that means practically
- The product is used on real authorization work, not only sold for it
- The sharp edges we found are the ones the product guards against
- Security requirements are build constraints, not a page on this website
Next step