How long does an ATO take? If you ask NIST, you’ll get silence — no publication in the 800 series commits to a number. If you ask a vendor, you’ll get whatever number sells their platform. If you ask an ISSO who has actually shepherded packages through eMASS, you’ll get the honest answer: a clean, well-resourced system can get an Authorization to Operate in 8–12 weeks, a typical DoD system takes 6–12 months, and a messy inherited system can grind on for 18 months or more.
This post breaks down where that time actually goes, step by step, so you can estimate your own timeline and defend it when leadership asks why the ATO isn’t done yet.
The Short Answer, by Scenario
| Scenario | Realistic timeline |
|---|---|
| New system, heavy control inheritance, cooperative AO, dedicated team | 8–12 weeks |
| Typical new DoD system, moderate inheritance, normal staffing | 6–12 months |
| Legacy system being authorized for the first time | 12–18+ months |
| Reauthorization of a well-maintained system | 2–4 months |
| Reauthorization of a neglected system (stale POA&M, expired artifacts) | 6–12 months |
Those ranges assume the RMF work is being done as intended. What moves you toward the fast end or the slow end is almost never the security of the system itself — it’s process, people, and paperwork discipline. I covered the failure patterns in detail in Why Your ATO Is Delayed; this post is about the calendar.
Why Nobody Official Will Give You a Number
NIST SP 800-37 defines the RMF steps but deliberately says nothing about duration, because the framework has to fit everything from a standalone lab enclave to a global weapons platform. DoD components layer their own processes on top — eMASS workflows, component-level review boards, AO queues — and every one of those adds calendar time that no framework document accounts for.
That’s why every published “ATO timeline” you find is either a marketing best case or a shrug. The useful way to estimate is to walk the steps with realistic durations attached.
How Long Does an ATO Take at Each RMF Step?
Prepare and Categorize: 2–4 weeks
Categorization itself is fast — walking the information types through CNSSI 1253 and settling on your confidentiality, integrity, and availability impact levels takes days, not weeks. What takes time is getting agreement. The system owner wants Moderate because High means more controls; the data owner insists some information type pushes a category up; the ISSM wants it settled before anything gets registered in eMASS. Budget two to four weeks for the discussion, not the paperwork.
Select: 2–4 weeks
Control selection moves quickly when inheritance is clear. If your hosting environment provides a solid common control package, you may inherit half or more of your baseline and this step is nearly administrative. If inheritance is ambiguous — nobody can tell you exactly which controls the enclave provides versus what you own — this step quietly bleeds into everything that follows and you’ll pay for it during assessment.
Implement: 2–6 months
This is the long pole. STIGs have to be applied and validated, scan findings remediated, and the SSP and control narratives written to reflect what was actually built. For a typical Moderate-baseline system with a few hundred applicable controls, two to six months is normal depending on engineering support. Documentation lags are the silent killer here: the technical work finishes, but narratives and artifacts trail weeks behind, and the assessment can’t start until the package tells a consistent story.
Assess: 1–3 months, plus the scheduling queue
The assessment itself — an SCA or validator team reviewing controls, running scans, interviewing staff — usually takes two to six weeks. The hidden cost is the queue: assessor teams book out weeks or months in advance, and if your package slips its window, you go to the back of the line. Missing an assessment window over an incomplete artifact set is one of the most expensive mistakes in the whole process, which is why a pre-submission scrub matters (the same discipline covered in Common eMASS Mistakes That Delay Your ATO).
Authorize: 2 weeks–2 months
After the SAR is finalized and the POA&M is built for residual findings, the package routes to the Authorizing Official. AOs are senior people with day jobs and a stack of packages ahead of yours. A responsive AO shop turns a clean package in a couple of weeks; a backed-up one can take two months. High-severity open findings trigger questions, and every question-and-answer round trip adds a week or more.
What Actually Causes the Delays
- Open high-severity findings. Nothing stalls an authorization decision like CAT I findings without credible mitigations. A disciplined POA&M with realistic milestones is the difference between “authorize with conditions” and “come back later” — the full workflow is in POA&M Management: How ISSOs Actually Track and Close Findings.
- Artifact churn. Diagrams, SSP versions, and scan results that don’t match each other force rework cycles measured in weeks.
- Unclear inheritance. Every control where ownership is fuzzy becomes an assessment finding, and every finding becomes calendar time.
- Staffing gaps. One ISSO covering five systems means every system’s package moves at one-fifth speed.
- Assessor and AO availability. Queues you don’t control — the only defense is never missing a window you’ve been given.
Red Flags Your Timeline Is About to Slip
Watch for these early: control narratives still say “TBD” a month before the assessment window; the network diagram is older than the last major change; scan results in the package are more than 30 days old; nobody can name the AO’s current turnaround time; or engineering treats documentation requests as optional. Any one of these usually costs a review cycle. Two or more usually cost a quarter.
How ISSOs Compress the Timeline
You can’t control the AO’s queue, but you can control whether your package ever waits on you. The compressions that actually work: write control narratives while implementation happens instead of after; keep a living artifact index so nothing expires unnoticed; scrub the package against the assessor’s checklist before submission, not after the first rejection; pre-brief the ISSM and AO staff on known residual risk so nothing in the SAR surprises them; and keep the POA&M current weekly so it’s always submission-ready.
Teams that do these things consistently land in the fast half of every range above. Teams that don’t donate months to rework.
Track every ATO milestone in one place
The RMF ATO Checklist ($27) is the exact step-by-step tracker I use to keep packages moving — every artifact, every phase gate, every pre-submission check, in one spreadsheet.
Final Thoughts
So, how long does an ATO take? Plan for six to twelve months on a typical DoD system, fight for the conditions that make 8–12 weeks possible — strong inheritance, dedicated documentation time, an assessment window you never miss — and treat every week your package spends waiting on rework as the most preventable delay in the entire process. The timeline is mostly a reflection of package discipline, and package discipline is the one variable the ISSO fully owns.
Related reading: How to Get an ATO Step by Step: The RMF Process Explained by an ISSO
Leave a Reply