What CR26 asks of a trust center.
CR26 writes these rules as obligations on a trust center, and every one of them binds the provider. A trust center must give agencies documented programmatic access to all certification data. It must log that access and keep summaries of it for at least six months. It must maintain an inventory and history of the federal agency users and systems that hold access. Those rules bind at your next assessment.
Read the rules and the datesThe trust center runs in your account, not ours.
We ship the trust-center software, and you run it in your own account, in-boundary. It serves your certification package to agencies through one documented route, machine-readable and human-readable from the same source. It logs the access, and the inventory of agencies holding access comes from that log. The public key that verifies our signature is published ungated, so an agency can verify your certification data with no TRGR account and no relationship with us. TRGR does not operate a trust center and is not itself FedRAMP-compatible. Every CR26 trust-center rule binds the provider, and the provider is you.
The certification package we generate, and what AI drafts
The Security Decision Record
The Security Decision Record replaced the System Security Plan for a CR26 certification. We generate it as machine-readable JSON, so the authorization record an agency receives is structured data rather than a word-processor document.
What CR26 changed about the packageThe Certification Package Overview
CR26 requires the Certification Package Overview in both human-readable and JSON form. We generate both, rendered from one source, so the two forms cannot disagree.
What the overview isThe vulnerability reports
We generate two vulnerability reports in human-readable and machine-readable form: a detail report of the active vulnerabilities, and a separate report of the ones a provider has formally accepted. CR26 moved the Plan of Action and Milestones to the agency and made these reports its input, so they are the documents the agency now works from.
When the vulnerability rules take effectThe ongoing certification report
CR26 requires an ongoing certification report each reporting period. We generate it in human-readable and machine-readable form, so an agency sees the current certification status between assessments.
When the CR26 rules take effectThe significant change notification
When a change carries a CR26 reporting duty, we generate the significant change notification in human-readable and machine-readable form. A run that finds no such change generates none.
What CR26 changed about the packageThe incident report
We generate the CR26 incident reports from the incident register, in human-readable and machine-readable form, one report per incident. An empty register produces a notice that it is empty rather than a fabricated report.
What CR26 changed about the packageA practitioner reviews and signs
AI drafts the narrative and the evidence mapping. The package structure, the digests, and the signature involve no model. A practitioner reviews the draft and approves it through the kernel gate, and a FedRAMP package that fails its constraint check is never delivered. Your own practitioner signs, and our signature notarizes that self-attestation, so an agency can verify the exact bytes and see that nothing changed after signing.
Where the practitioner signs offOr an independent TRGR review
A TRGR practitioner reviews and signs, so an agency receives a third-party review instead of the provider's own attestation. The affiliation is recorded inside the signed bytes, so a self-attestation cannot pass as a TRGR review.
Self-attestation or independent reviewWritten to your own bucket
The runner writes the finished artifacts to a bucket you own. Your trust center serves them from there, in-boundary, through one route in both machine-readable and human-readable form.
Where certification data lives now
One control, in both forms
This is what an agency pulls. The same control as machine-readable OSCAL, and as a row a person can read, rendered from one source.
{
"control-implementation": {
"implemented-requirements": [
{
"uuid": "ir-ac2-0001",
"control-id": "ac-2",
"props": [
...Illustrative OSCAL, not a real package.
The same control, in human terms.
How the package reaches an agency.
We generate the package, a practitioner signs it, and the trust center you run serves it.
Generate the package
We generate the Security Decision Record, the Certification Package Overview, and the vulnerability reports, each in the forms CR26 asks for. AI drafts the narrative text and the evidence mapping.
A practitioner reviews and signs
Your own practitioner reviews what AI drafted and signs the package through the kernel gate. TRGR's signature over that approval makes it tamper-evident, so an agency can confirm the package was not changed after it was signed. Until that happens, nothing is served.
Write to your bucket
The runner writes the signed artifacts to a bucket in your own account.
Serve it in-boundary
Your trust center serves the artifacts to agencies through one documented route, machine-readable and human-readable, and logs every access.
An agency verifies the signature
The public key is published ungated, so an agency can verify what it pulled without a TRGR account.
A package is accurate the day it is signed.
The system keeps changing after that. Continuous monitoring compares the running system to the authorized baseline and surfaces drift from the approved state. A control-relevant configuration change produces a finding in seconds through the event path. The scheduled sweep still runs behind it, and the sweep is what proves the system was looked at, because an event can show that something changed but never that nothing did. The event path cannot see a deletion or a resource outside its coverage, and it is only as live as the recorder that feeds it, so a run that cannot confirm the recorder was recording refuses to attest. The work is spread across the year instead of piling up before an assessment. The detection is deterministic. A model ranks a deviation's severity and classifies the remediation path, and it never hides a finding: with no model, or on a model error, the finding is still reported and routed to a human. Readiness is scored against the indicators an assessment works from, and gaps are ranked by remediation priority. Nothing is applied automatically, and a practitioner decides what happens.
Explore the agent suiteIf you are not authorized yet, we build that first.
All of this assumes a system that already holds an authorization. If yours does not, our practitioners build it first, boundary through ATO. That is an engagement they run phase by phase, and the certification package and the trust center come after it, on a system that is authorized.
Built for federal contractors who
- have to serve certification data to an agency before their next assessment.
- owe a FedRAMP certification package and want it as structured data.
- want the trust center inside their own account and their own boundary.
- need a FedRAMP authorization, or a NIST 800-171 posture, to sell to an agency.
- want the package to stay current long after it is signed.