FedRAMP Management Engine
LIMITED RELEASEContinuous authorization, at FedRAMP 20x cadence.
The Engine generates the machine-readable authorization packages FedRAMP 20x and the 2026 Consolidated Rules ask for, and the OSCAL artifacts the Rev 5 path still needs. It deploys inside your authorized boundary, so customer data never leaves your environment.
Closed beta · running in production at Novaprospect
Request beta access →The problem
The authorization cadence is changing.
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. 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 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 files rather than 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. Every state change is logged and linked to the change that caused it.
Capability
What it is built to do, and what limited release means.
Each claim below is labelled with its basis. Designed means it is what the architecture produces. Limited release means it is running, against named engagements rather than open to anyone who asks.
Full Rev 5 Moderate baseline as OSCAL
Native OSCAL 1.x SSP, component definitions, assessment plans and POA&M documents across the Rev 5 control families, interoperable with any OSCAL-aware tooling.
RFC-0024 machine-readable packages
Generates the FedRAMP machine-readable package format mandated from 30 September 2026. The rules are the schema; there are no template files to fill in.
Evidence sourced at origin
Beacon's KSI emissions and Citadel's signed host results land as OSCAL origin references. Control state is read from live infrastructure — Terraform state, cloud APIs, Kubernetes, IAM policy — rather than typed into a spreadsheet.
POA&M lifecycle end to end
Findings flow scanner → POA&M entry → remediation commit → verification, with every state change logged and linked to the change that caused it. Balance Improvement Releases are scheduled obligations.
Both pathways at once
Built to hold a 20x package and a Rev 5 authorization in the same record through the Consolidated Rules transition window, so an organization moving between pathways is not maintaining two systems of record.
Limited release
The Engine is not generally available. It is running and demonstrable, and we will tell you exactly which artifact generators are complete rather than demoing around the gaps.
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).
Paired with the platform
Four evidence sources. One record, two formats.
The Engine ingests evidence from Citadel, NAICOM, and Beacon natively. Host state, the per-issue record of AI-assisted work, KSI emissions and infrastructure scans all land in the same 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 provenance record from NAICOM, or a live infra-scan artifact. Nothing is hand-keyed.
Evidence with an origin
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.
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.
Who this is for
Four things that make the Engine worth your time.
These are not gates — if your situation is close but not exactly this, the conversation is still worth having.
A live or in-flight FedRAMP authorization
A Rev 5 authorization you maintain, or a 20x Phase 2 / Phase 3 application in motion. The Engine is a system of record, so it needs a package to be the record of.
A transition-window problem
You are on the traditional path and the Consolidated Rules take effect 30 September 2026, or you are moving to 20x and need both pathways to hold together while you do.
Infrastructure the Engine can read
Terraform state, cloud APIs, Kubernetes, IAM policy — a read path that lets control state come from the running system.
Someone who owns the package
A named compliance or security-engineering contact who will hand artifacts to a 3PAO, and who can tell us whether what we generate is what their assessor accepts.
What the conversation covers
Generated artifacts you can open.
- The running Engine against a real package — not slides, and not a recorded video.
- Generated OSCAL artifacts you can open: SSP, component definitions, assessment plan, POA&M.
- The RFC-0024 machine-readable package, and what changes about your submission on 30 September 2026.
- How Beacon KSI emissions and Citadel host results arrive as origin references rather than re-keyed evidence.
- A straight answer on which generators are complete and which are not, because it is in limited release.
What we need from you
Thirty minutes and a named contact.
- A named compliance or security-engineering contact who owns the authorization package.
- Where you are: Rev 5 maintained, 20x applying, or moving between the two.
- The shape of the infrastructure the Engine would read control state from.
- The date driving this — an assessment, a submission, or the 30 September 2026 deadline.
FAQ
What people usually ask first.
Is the Engine generally available?
No. The FedRAMP Management Engine is in limited release. It is running and demonstrable today, and we will tell you plainly which artifact generators are complete rather than demoing around the gaps.
Do I need Beacon as well?
No, but they are built for each other. The Engine consumes Beacon KSI emissions natively as the authoritative 20x package; without Beacon it still generates Rev 5 OSCAL artifacts and runs POA&M lifecycle from other evidence sources.
What happens on 30 September 2026?
RFC-0024 makes the FedRAMP machine-readable package format mandatory for all CSPs, Rev 5 and 20x alike. The Engine generates that format natively, which is the reason its output is JSON and OSCAL rather than documents.
Can it hold a Rev 5 authorization and a 20x package at the same time?
That is what it is designed for. The transition window means many organizations are maintaining a traditional authorization while standing up 20x, and the Engine is built so that is one record rather than two systems.
Where does it run?
Inside your authorization boundary. Control state, evidence and generated artifacts stay in your environment; nothing is sent to Novaprospect.
How is it available?
As a closed beta. The Engine runs in production at Novaprospect and holds its own authorization package, and access goes to organizations that ask for it and say what they would run it against. Request beta access from this page and you get an answer. No rate is published for it. Acquisition conversations are open separately; the acquisition page sets out what a buyer inherits.
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 host-state results feeding the Engine as CM-family and SI-family evidence.
Get ahead of the 20x cadence.
The Engine is running today for organizations pursuing FedRAMP 20x Phase 2 or Phase 3, and for teams maintaining a Rev 5 authorization through the Consolidated Rules transition window. There is no self-serve route to it.
Closed beta · running in production at Novaprospect
Request beta access →