The 18-month ATO. A process failure.

The Bottleneck

The Risk Management Framework (RMF) as defined in NIST 800-37 rev2 prescribes six steps: Categorize the information system based on the impact of a breach. Select a baseline of security controls from NIST 800-53 rev5 appropriate to that categorization. Implement the selected controls across the system's infrastructure, applications, and operational processes. Assess the implementation to verify each control operates as intended. Authorize the system by having a senior official accept the residual risk documented in the assessment. Monitor the system continuously to ensure the authorized security posture persists. Each step has clear inputs and outputs. None of them inherently requires months of calendar time. The categorization step takes days when the system's data types and mission impact are well understood. Control selection is deterministic once the categorization is established. Implementation timelines depend on the system's maturity, but the assessment and authorization steps should be measured in weeks, not quarters.

The timeline expands because of what happens between the steps. Evidence assembly is the primary bottleneck. For a moderate-impact system, the NIST 800-53 rev5 baseline selects hundreds of controls and control enhancements. Each control requires evidence that the control is implemented, operating effectively, and producing the intended security outcome. That evidence must be collected from the running system, organized by control family, cross-referenced to the System Security Plan narrative, and packaged for the assessor. In a manual process, engineers take screenshots of configurations, export log samples, compile access control lists, and write narrative descriptions of how each control is satisfied. This collection cycle takes months. By the time the last control family is documented, the evidence collected for the first family is already stale. The infrastructure has changed. New resources have been deployed. Security group rules have been modified. Access control policies have been updated. The evidence package describes a system that no longer matches the running environment.

Scheduling compounds the delay. Independent assessors have limited availability. Authorizing Officials schedule authorization decisions around competing priorities. The assessment phase itself spans weeks as assessors review documentation, interview system administrators, and validate evidence against the running environment. When the assessor identifies discrepancies between the documented controls and the actual implementation, the assessment pauses while the system owner remediates gaps and re-collects evidence. Each remediation cycle adds weeks. Each re-collection cycle risks introducing new staleness into previously verified evidence. The calendar stretches from the planned six months to twelve, then to eighteen. The authorization decision, when it finally arrives, certifies a security posture that may have changed multiple times since the assessment began. The ATO is granted for a snapshot that existed briefly during the assessment window. It may not reflect the system's current state on the day the authorization letter is signed.

The Problem

Evidence decay is the structural flaw in manual authorization processes. A configuration snapshot collected on January 15 documents the system's state on that date. By February 15, the infrastructure has changed. New compute instances have been provisioned. Storage encryption settings have been modified to accommodate a new data classification requirement. Network access control lists have been updated to support a new integration. IAM roles have been created for a new operations team member. None of these changes invalidated the January evidence at the time they occurred. But collectively, they mean the January evidence no longer describes the February system. The assessor reviewing the package in March is evaluating artifacts that describe a system from two months ago. When they compare those artifacts to the current environment during validation interviews, discrepancies surface. The assessment stalls while the system owner reconciles the documentation with reality.

The ATO factory emerged as organizations tried to scale this broken process. Dedicated compliance teams rotate through systems, applying the same manual evidence collection methodology to each one in sequence. The factory model treats authorization as a production line: scope system A, collect evidence for system A, submit system A for assessment, move to system B. The fundamental problem persists at scale. Evidence collected for system A goes stale while the team works on system B. When the assessor returns findings on system A, the compliance team is deep in system B's evidence collection. Context switching between systems introduces errors. Engineers who were interviewed about system A's access controls three months ago may not remember the specific configurations they described. The factory produces volume, but each unit suffers the same quality degradation. Twelve-month timelines per system multiply across a portfolio of ten systems. The organization finds itself in a perpetual authorization cycle where no system is ever fully current and every assessment begins with re-collection.

The cost of this cycle extends beyond labor hours. Contract performance periods begin regardless of authorization status. Systems that cannot obtain their ATO before the contract start date operate under interim authorizations, waivers, or risk acceptance memoranda that carry their own oversight burden. Mission-critical systems that need rapid deployment face a choice between waiting eighteen months for authorization or operating under elevated risk with reduced oversight. Neither outcome serves the mission. The authorization process was designed to manage risk, not to create it. When the process itself becomes the risk, because it cannot keep pace with the systems it governs, the framework is not at fault. The implementation methodology is at fault. The RMF does not prescribe manual evidence collection, static documentation, or quarterly review cycles. Those are implementation choices. Different implementation choices produce different timelines.

The SSP Burden

The System Security Plan is the authoritative document that describes a system's security architecture, control implementations, and authorization boundary. For a moderate-impact system assessed against the NIST 800-53 rev5 baseline, the SSP typically exceeds 300 pages. Each control family requires narrative descriptions of how the organization satisfies each control, what technical mechanisms enforce the control, what evidence demonstrates the control's effectiveness, and what residual risks remain. These narratives must be specific to the system, not generic boilerplate copied from a template. An assessor who reads the same access control narrative across five different systems in an organization's portfolio will flag the repetition as evidence that the descriptions do not reflect actual implementations. Each system has unique access control mechanisms, unique user populations, unique data flows, and unique technical architectures. The narratives must reflect those distinctions.

Manual narrative authorship is where documentation timelines expand most dramatically. A security engineer who understands the technical implementation of AC-2 (Account Management) for a specific system must translate that understanding into a written narrative that an assessor can evaluate. The engineer describes the identity provider configuration, the role-based access control model, the account provisioning workflow, the access review frequency, and the technical enforcement mechanisms. This narrative takes hours to write correctly for a single control. Multiply that across hundreds of controls and the documentation effort consumes months of engineering time. The engineers writing these narratives are the same engineers maintaining the systems. Every hour spent writing documentation is an hour not spent on security operations, incident response, vulnerability management, or system enhancement. The documentation burden competes directly with the operational work that produces the security posture the documentation is supposed to describe. By the time the last narrative is written, the first narratives describe an implementation that has already changed. The SSP is outdated before the assessor receives it.

The architecture takes a different position: the SSP is a computation, not a manuscript. The capability register names it documents as computation, and Rampart's design holds the SSP, the POA&M report, the assessment package, and per-control narratives as managed document kinds, each in one of three states: current, stale, or regenerating. The document machine is driven by change: a posture shift, a framework-version diff, or a narrative-input change marks the affected document stale, names its cause, and queues regeneration from the event that triggered it. The narrative engine is specified the same way. Each control narrative declares the data it requires, the structure it follows, and machine-checkable quality criteria, so a draft is judged against declared standards, not template boilerplate with variables substituted. Artificer is the drafting surface, and the boundary is written into the design: nothing a model infers counts as evidence until a named human confirms it. AI-drafted text informs; it never authorizes. The SSP that reaches the assessor is a view over the living assessment record, not a manuscript that began drifting the day it was finished.

Evidence Assembly

An evidence package for a moderate-impact system must demonstrate that every one of hundreds of selected controls is implemented and operating effectively. Each control requires specific evidence types: configuration artifacts proving the control is deployed, operational records proving the control is functioning, and test results proving the control produces the intended security outcome. For AC-2 (Account Management), the package must include the account management policy, evidence of the provisioning workflow in operation, access review records showing periodic reviews were conducted and acted upon, deprovisioning records showing timely account removal, and audit logs demonstrating enforcement of account restrictions. That is one control. The full package spans every control family: Access Control, Awareness and Training, Audit and Accountability, Security Assessment, Configuration Management, Contingency Planning, Identification and Authentication, Incident Response, Maintenance, Media Protection, Physical Protection, Planning, Personnel Security, Risk Assessment, System and Services Acquisition, System and Communications Protection, and System and Information Integrity.

Manual assembly takes months because every evidence artifact requires human action. An engineer logs into a console, navigates to the relevant configuration page, takes a screenshot, saves it with a filename that identifies the control it supports, and uploads it to the evidence repository. The compliance team reviews the artifact, confirms it addresses the control requirement, and cross-references it in the evidence matrix. For a single control, this process takes 30 minutes to several hours depending on the complexity of the evidence required. Multiply that across hundreds of controls and account for the coordination overhead of multiple engineers contributing artifacts across different timelines, and the assembly phase stretches to three to six months. During that period, every artifact already collected is aging. Evidence freshness is not a binary state. It degrades continuously from the moment of collection. An artifact collected on day one of a six-month assembly cycle is six months old when the package is submitted. The assessor will question whether that artifact still reflects the current environment.

The design replaces the human collection loop with declared requirements. In the architecture, each control declares the evidence it needs: the evidence type, the source category, the assessment objective it serves, and a freshness window. The collection engine is specified to resolve those declarations against discovered infrastructure rather than against a hand-maintained mapping. The architecture works the AC-2 example directly: a user roster and RBAC policy resolved from the discovered identity provider, an access review log from the audit system, each carrying a 90-day freshness window; where a source is not discovered, the gap is computed, not noticed months later. Sentinel is the capability chartered for that work: discovery, evidence collection, scheduled scanning, and drift alerting over a universal connector interface, with self-healing collection named in its register entry. Freshness is law rather than intention: past its declared horizon, evidence demotes to contested instead of silently persisting, and a re-observation task is emitted for the owning collection controller, which is the mechanism behind the evidence expiration lifecycle. Integrity rides the event spine: every event enters a per-organization SHA-256 hash chain sealed under Merkle checkpoints, so an artifact's provenance is checkable rather than asserted.

Assessment Prep

Preparing for an assessor requires more than collecting evidence. The evidence must be organized by control family, cross-referenced to the SSP narrative for each control, indexed so the assessor can navigate from any control to its supporting artifacts, and packaged in a format the assessor can review independently. Personnel must be identified for each control family interview. Operational processes must be documented for observation. The authorization boundary must be current and accurately reflected in the system description. POA&M items must be documented with remediation plans and timelines. The quality and completeness of this preparation determines the assessment's pace. Assessors who receive well-organized evidence packages complete their review in weeks. Assessors who receive disorganized artifacts spend weeks requesting clarification before the substantive review begins.

Disorganized evidence packages are the most common cause of extended assessment timelines. Assessors who receive artifacts scattered across shared drives, email threads, and ticket systems spend days reconstructing which evidence supports which control. Narratives that describe intended implementations rather than observed reality create immediate credibility problems: when the assessor interviews the system administrator and the answers do not match the written narrative, every subsequent narrative is treated with skepticism. Missing cross-references between controls and their supporting evidence force the assessor to request clarification for each gap, turning a three-week assessment into a six-week assessment. The cost of that delay falls entirely on the organization. Every hour the assessor spends hunting for evidence is an hour not spent validating the actual security posture. Extended assessments also increase the risk of evidence staleness during the assessment window itself, compounding the very problem the organization was trying to avoid.

Alliance is designed for exactly this handoff. Its register entry defines cross-org trust as proof-exchange, not document-exchange, and admits external assessors as scoped, time-boxed actors with as-of evidence lenses. The specified assessment machine seals a frozen view: an AssessmentSnapshotSealed event anchors the snapshot to a named position in the event log, with a SHA-256 digest computed over its canonical bytes, so the assessor reads the frozen view while the team works live, and both project from the same log. The design's evidence invariant states the export posture plainly: posture is exportable as machine-verifiable attestation a third party can check cryptographically, OSCAL-native and selectively shareable. An assessor who accepts structured submissions gets machine-readable packages in the format NIST specifies; one who wants to drill gets every control in Rampart, its evidence chain, and its citable anchor. Neither gets a shared drive folder with ambiguous filenames.

The Living ATO

Continuous authorization replaces the point-in-time snapshot with a living authorization package that reflects the system's current security posture at all times. The concept is not new. NIST 800-37 rev2 explicitly describes ongoing authorization as an alternative to the traditional three-year reauthorization cycle. FedRAMP has formalized continuous monitoring requirements that feed into ongoing authorization decisions, and FedRAMP 20x points the program at continuous authorization directly: Key Security Indicators validated against running systems, with machine-readable OSCAL packages as the submission format. The Department of Defense's RMF implementation guidance acknowledges that continuous monitoring data should inform authorization decisions on an ongoing basis rather than exclusively at periodic reauthorization boundaries. The framework supports continuous authorization. The challenge has been implementing it. Manual processes cannot produce continuous evidence. Quarterly collection cycles cannot track daily infrastructure changes. Static SSP documents cannot reflect dynamic architectures.

The point-in-time paradox is structural. An ATO authorizes a system to operate based on the risk posture observed during the assessment. The assessment evaluates a specific configuration at a specific point in time. The authorization letter is signed days or weeks after the assessment concludes. Between the assessment and the signature, the system continues to operate. Patches are applied. Configurations are updated. Users are provisioned and deprovisioned. The system authorized on paper may differ from the system running in production on the day the authorization takes effect. A three-year ATO means the authorization decision made in 2024 governs the system through 2027. The system in 2027 will bear little resemblance to the system assessed in 2024. Cloud infrastructure will have been re-architected. Application code will have been rewritten. The operating system versions documented in the SSP will have reached end of life and been replaced. The paradox deepens with every change.

The capability register names this directly: continuous authorization, live authorization state maintained event-by-event, with point-in-time assessments and readiness scores defined as projections of that state. Rampart is chartered as the workspace that renders those projections, posture computed per control from evidence-satisfaction state, never a point-in-time construction and never a checklist. The dependency map is equally explicit: change events from Sentinel are declared to re-evaluate posture, and evidence freshness decay drives the authorization state. Garrison is specified as the temporal estate: what existed at time T, ephemeral entities included, compliance history retained beyond an entity's lifespan, so the authorization boundary has a queryable history instead of a diagram that aged out of truth. The spine's experience law makes that history citable: every as-of answer names the log range and sealed checkpoint that make it true, receipt-backed history rather than bare assertion. An Authorizing Official's question, what changed since the last decision and what did it do to control satisfaction, is a query in this design, not a quarterly research project.

Re-Authorization

The standard authorization cycle grants an ATO for three years, after which the system must be reauthorized. In theory, continuous monitoring during the authorization period should maintain awareness of the system's evolving risk posture so that reauthorization builds on established knowledge rather than starting from scratch. In practice, most organizations experience reauthorization as a cold start. The SSP was written three years ago and describes an architecture that no longer exists. The evidence package was assembled for the previous assessment and has been aging in a document repository. The infrastructure has changed so extensively that the previous authorization boundary may no longer be accurate. New systems have been integrated. Old systems have been decommissioned. Network topologies have been restructured. The compliance team that prepared the original assessment may have turned over. The reauthorization engagement requires re-discovering the system, re-documenting the architecture, re-collecting all evidence, and re-assessing every control. The three-year cycle does not save work. It defers work.

The cold-start problem is compounded by the annual assessment requirement that many agencies mandate between full reauthorization cycles. These annual assessments are supposed to verify that the security posture documented in the ATO package still reflects the running system. When the SSP has not been maintained, the annual assessment becomes a mini-reauthorization: the assessor discovers discrepancies between the documentation and the current environment, findings are generated, remediation is required, and the evidence package must be updated. Each annual assessment consumes months of preparation time because the documentation drifted from reality throughout the preceding year. The organization spends more total effort on periodic re-assessment than it would on continuous maintenance. The cycle repeats: document, drift, re-document, drift, re-document. Each iteration starts from a larger documentation gap than the previous one.

Continuous authorization removes the cold start by construction: in a design where the assessment never stops being computed, the reauthorization engagement starts from a current readiness projection in Rampart rather than a three-year-old manuscript, and the assessor's as-of lens reaches the whole trajectory: when controls degraded, how they were remediated, and where the system stands today, each answer anchored to the sealed log. The POA&M machine carries what the architecture calls delayed-state honesty: a slipped milestone moves the item to a delayed state that is assessor-visible, the new date recorded beside the old, never re-dated silently. The authorization ruling itself stays where it belongs: the design binds it as a Tier-3 act, a human decision no automation path is architecturally permitted to make. Citadel is chartered as the command surface where the resulting action items and approvals appear as role-prioritized cards; the dashboard displays, humans act. What the three-year boundary meets in this design is not a re-discovery project. It is a posture trajectory with receipts.

The New Timeline

The 18-month ATO timeline decomposes into identifiable delays, and each delay has a structural cause that continuous evidence eliminates. Evidence collection accounts for the largest share: three to six months in a manual process, reduced to zero when evidence flows continuously from the running system. SSP authorship accounts for another two to four months: narrative descriptions written by engineers who are simultaneously maintaining the systems they describe. When the SSP is a living document updated automatically as the system evolves, the initial authorship effort decreases and the maintenance burden disappears. Evidence re-collection after assessor findings accounts for one to three months per remediation cycle: re-collecting stale artifacts, re-verifying configurations, re-interviewing engineers. When evidence is continuous and current, there is no re-collection cycle. Assessor scheduling and review time remains constant regardless of methodology, but assessors who receive structured, navigable evidence packages with clear control-to-evidence mappings complete their reviews faster.

The structural improvement is not incremental. It is categorical. The manual process requires sequential phases that cannot overlap: collect evidence, then write narratives, then review the package, then submit for assessment, then remediate findings, then re-collect, then resubmit. Each phase waits for the previous one to complete. The continuous model eliminates the sequential dependency because evidence collection, narrative maintenance, and posture assessment all happen concurrently as ongoing processes rather than discrete phases. In that model, the system owner is always assessment-ready because the authorization package is always current. Engaging the assessor does not require a preparation sprint. The package is ready today because it was ready yesterday and it will be ready tomorrow. The assessor's review begins immediately upon engagement because the evidence does not need to be assembled. It already exists in a structured, navigable format with complete provenance metadata and cryptographic integrity verification.

This is the case for a compliance control plane. Redoubt Forge's architecture holds defenses as desired state, computes posture from evidence-satisfaction, and reports divergence, so the phases that consumed the ATO calendar stop existing as phases. Collection is Sentinel's charter, declarative and continuous, never a quarterly sprint. Inventory is Garrison's temporal estate, not a manual census. The SSP and the POA&M report are managed documents specified to regenerate when their inputs change, and the design has Artificer draft each narrative and a named human confirm it before it counts. Assessment is a projection Rampart is designed to seal on demand: a frozen, digest-verified view over the same log the team works from, exportable as OSCAL-native, machine-verifiable attestation through Alliance. The federal program is moving toward exactly this shape: FedRAMP 20x names Key Security Indicators validated against running systems, with machine-readable OSCAL packages mandated for providers. A design in which the authorization package is computed does not compress the eighteen months. It deletes the phases that produced them.