FedRAMP Management Engine
Continuous authorization, at FedRAMP 20x cadence.
The Engine generates the machine-readable authorization packages FedRAMP 20x and the 2026 Consolidated Rules ask for — Key Security Indicators emitted continuously, OSCAL artifacts for the Rev 5 path, and the structured evidence ledger that ties them together. It deploys inside your authorized boundary, so customer data never leaves your environment.
The problem
The cadence is changing. The tooling has to change with it.
Traditional FedRAMP authorization consumes two to four full-time engineers for 12 to 24 months. Continuous monitoring then consumes them indefinitely: monthly ConMon deliverables, quarterly scans, annual reassessments, POA&M tracking, SSP drift reviews.
FedRAMP 20x rewrites that cadence. Authorization compresses to a few months. ConMon becomes a continuous stream of Key Security Indicators — machine-validated every three days, not summarized every quarter. The Consolidated Rules 2026 retire FedRAMP-provided templates entirely in favor of structured, machine-readable packages. The artifact is the rules.
The Engine is built for that model on both sides: it reads infrastructure state continuously, emits the KSI evidence 20x asks for, and generates the OSCAL packages Rev 5 still requires for organizations on the traditional path through 2028.
How it works
Four pillars of automated authorization.
Each pillar produces a concrete artifact the platform generates, retains, and keeps current against live infrastructure state.
Infrastructure-derived control state
Control implementation status is read from live infrastructure — Terraform state, cloud APIs, Kubernetes, IaM policy — not from spreadsheets. If the infrastructure drifts, the SSP and the KSI stream both reflect it.
Machine-readable artifacts
SSP, SAP, SAR, POA&M, and the FedRAMP Consolidated Rules 2026 machine-readable package format are generated natively. OSCAL JSON for Rev 5; structured KSI evidence packages for 20x. Hand off to your 3PAO as machine-readable, not as 400-page Word documents.
Continuous, persistent validation
Per-control evidence is captured continuously and timestamped. For 20x Moderate, KSI validation runs every three days minimum and the structured evidence package stays current between assessments — not assembled in a sprint before the annual review.
POA&M lifecycle and BIR tracking
Findings flow from scanner → POA&M entry → remediation commit → verification. Balance Improvement Releases are scheduled as planned obligations under the consolidated rules, not as one-off projects. Every state change is logged and linked to the change that caused it.
At a glance — Rev 5 view
Every control family, live.
For the Rev 5 path, implementation status is computed against live infrastructure on every reconciliation pass. For 20x, the same infrastructure scan emits Key Security Indicators on a three-day cadence. Same data source, two output formats — pick the one your authorization is on.
Integrations
Reads the systems you already run.
The Engine ingests the infrastructure and security tooling that's already in your environment. No parallel inventory. No duplicate data entry.
Infrastructure & cloud
Controls are mapped to the IaC modules and cloud resources that implement them. When Terraform state changes, the SSP reflects it on the next reconciliation run.
- — Terraform, CloudFormation, Pulumi, and Helm state ingestion.
- — AWS GovCloud, Azure Government, Google Cloud Assured Workloads.
- — Kubernetes admission policy and service-mesh configuration.
- — Cloud IAM, KMS, logging, and backup service inventories.
Security tooling & ticketing
Findings from scanners and CSPM tools flow into the POA&M automatically. Remediation commits close the loop — each closure is linked to the change that verified it.
- — Vulnerability scanners — Tenable, Qualys, Wiz, Prisma Cloud.
- — SIEM & logging — Splunk, Elastic, Chronicle, Sentinel.
- — Ticketing — Jira, ServiceNow, Linear, GitHub Issues.
- — Identity — Okta, Entra ID, Authentik (for AC-family evidence).
POA&M queue
Every open POA&M has an owner, a control reference, a severity, and an SLA clock. The queue view is the day-to-day operational surface for your SecOps, DevOps, and GRC teams.
| ID | Finding | Control | Severity | Owner | SLA |
|---|---|---|---|---|---|
| PM-2026-0151 | rpm drift · app-03.prod · new openssl build | CM-8, SI-7 | ● moderate | DevOps | 7 days |
| PM-2026-0150 | SAST finding · container image cve-2026-1143 | SI-2, SA-11 | ● high | SecOps | 2 days |
| PM-2026-0149 | ConMon evidence gap · AC-2 quarterly review | AC-2, CA-7 | ● moderate | GRC Team | 14 days |
| PM-2026-0148 | NAICOM receipt missing signature on 2 commits | SA-11, AU-2 | ● moderate | Eng Lead | 21 days |
| PM-2026-0147 | openssl CVE-2026-1143 · 3 services | SI-2 | ● closed | DevOps | verified |
Paired with the platform
Four evidence sources. One record, two formats.
The Engine ingests evidence from Citadel, NAICOM, and Beacon natively. Host state, AI session receipts, KSI emissions, and infrastructure scans all land in the same evidence ledger — emitted as OSCAL for the Rev 5 path and as the Consolidated Rules 2026 machine-readable package for the 20x path, with per-control origin references your assessor can verify.
OSCAL SSP
One control-implementation stanza per control
Every origin-reference in the SSP points back to a signed event from Citadel, a session receipt from NAICOM, or a live infra-scan artifact. Nothing is hand-keyed.
"implemented-requirement": { "control-id": "cm-8", "description": "System Component Inventory", "origin-refs": [ { "source": "citadel", "kind": "osquery-result", "pack": "cm8-inventory", "hosts": 247, "sig": "ed25519:4b01…" }, { "source": "naicom", "kind": "session-receipt", "ref": "naic-f804", "sig": "ed25519:8c3a…" }, { "source": "engine", "kind": "infra-scan", "ref": "tf-state-2026-04-21", "sig": "ed25519:e019…" } ], "last-verified": "2026-04-21T09:16:21Z" }
Evidence, not attestation
Every origin reference in the SSP points to a signed event, verifiable without trusting Novaprospect.
Control families covered
AC, SC, AU, CM, SA, SI, and AI-RMF Map/Measure covered natively across the stack.
One audit surface
Assessors review one OSCAL artifact per control — not three siloed systems that have to be reconciled.
Stays current automatically
Drift between SSP narrative and live state is detected on every reconciliation cycle and surfaced as a POA&M candidate.
Compliance alignment
Machine-readable from day one.
The Engine speaks the formats FedRAMP, the PMO, and your 3PAO already use.
FedRAMP 20x · Phase 2 / Phase 3
Native KSI emission against the 56-KSI Low and 61-KSI Moderate baselines. Designed for the Q3-Q4 2026 wide-adoption window when 20x becomes the default authorization pathway.
Consolidated Rules 2026
Generates the FedRAMP machine-readable package format mandated by RFC-0024 (effective September 30, 2026). No template files to fill in — the rules are the schema.
NIST 800-53 Rev 5 · OSCAL 1.x
Full Rev 5 control-family coverage with native OSCAL SSP, component definitions, assessment plans, and POA&M documents. Interoperates with any OSCAL-aware tooling.
Architecture
Inherits your boundary, not ours.
The Engine is delivered as Docker containers with Helm charts and Terraform modules. It runs inside your existing authorization boundary — on-premises, customer cloud, or GovCloud tenant — under your controls.
Read access to your infrastructure is provided through short-lived cloud credentials scoped to inventory and configuration APIs. The Engine never writes to production systems; it writes OSCAL artifacts and evidence to a customer-owned data store.
No Novaprospect authorization is required to begin using the Engine. A managed GovCloud SaaS offering is on the roadmap once the company's own authorization is complete.
Elsewhere in the platform
Beacon →
Continuous Key Security Indicator emission for FedRAMP 20x. Plugs into the Engine or stands alone.
NAICOM →
AI-SDLC evidence the Engine consumes as SA-11, SI-7, and CM-family origin refs.
Citadel →
Signed osquery results feeding the Engine as CM-family and SI-family evidence.
Get ahead of the 20x cadence.
Early-access pilots are open to organizations pursuing FedRAMP 20x Phase 2 or Phase 3, and to teams maintaining a Rev 5 authorization through the Consolidated Rules transition window.
Get in touch