RMFInsider

An Interim Authorization to Test is a temporary authorization decision that lets you test a system in an operational environment or with live data before it has an ATO. CNSSI 4009-2022 defines it as temporary authorization to test an information system in a specified operational information environment, within the timeframe and under the conditions enumerated in the written authorization. In DoD practice it runs for less than 90 days, it is issued by the Authorizing Official, and it permits testing only. The system does not go operational under an IATT.

You need one when your test objectives cannot be met in a lab: you need the real network, the real interfacing systems, or real data. You do not need one to run a scan in an isolated enclave, and you do not need one because your ATO is late. Those are different problems with different fixes.

Here is where the rules actually live in 2026, what belongs in the request, and how to compress the timeline without giving the AO a reason to say no.

Where the IATT Rules Live Now

This is worth getting right, because the internet is full of citations to a document that no longer says what people claim it says.

The March 12, 2014 version of DoDI 8510.01 spelled IATT out directly. It stated that an IATT applies when the risk determination is being made to permit testing of the system in an operational information environment or with live data, that IATTs should be granted only when an operational environment or live data is required to complete specific test objectives, that they should expire at the completion of testing and normally cover a period of less than 90 days, and that operation under an IATT is for testing purposes only, meaning the system will not be used for operational purposes during the IATT period.

The current issuance, DoDI 8510.01 dated July 19, 2022, reissued that 2014 instruction and moved the detail. It names the decision types in the Authorize step and then states that the final risk determination and authorization decision definitions, including interim authorization to test, ATO, ATO with conditions, and denial of ATO, are on the RMF Knowledge Service. The 90-day figure did not disappear from DoD practice, it moved out of the instruction body. If you want the broader picture of what the 2022 reissue changed and what it left to other references, DoDI 8510.01 explained covers the structure.

The figure is still current and still citable. The DISN Connection Process Guide, which is live guidance, states that the Approval to Connect for an enclave operating under an IATT is normally for a period of less than 90 days in accordance with DoDI 8510.01. That same guide is where you will find the other useful fact: DoD RMF no longer permits an Interim Authorization to Operate. IATO is gone. If a program manager asks you for an IATO, they are working from pre-RMF muscle memory, and what they probably want is either an IATT or an ATO with conditions.

Service-level policy names IATT as a decision type without redefining it. AFI 17-101, dated 6 February 2020, lists interim authority to test alongside ATO, ATO with conditions, and denial as the decisions an AO may issue. Your component’s RMF process guide is the place to look for the local submission mechanics and any locally tightened duration.

When You Actually Need an IATT

The trigger is narrow. You need an IATT when all three of these are true: the system does not have an ATO, your test objectives require an operational environment or live data, and the testing carries risk the AO has to formally accept. Concrete cases:

• Developmental or operational test events that require connection to a live DoD network segment.
• Interoperability testing against production interfacing systems where a lab stand-in does not reproduce the behavior.
• Testing with live operational data because synthetic data does not exercise the failure modes you are hunting.
• A new capability that must sit inside the operational enclave to be tested against real traffic volume and real latency.
• Government acceptance testing on delivered hardware that has to be racked in the production facility.

And the cases where you do not need one, which is where the schedule pressure usually comes from:

• Testing in an isolated lab with no operational connection and no live data. That needs nothing from the AO beyond whatever your local lab policy requires.
• A component or tool that will never operate independently and inherits into another system’s boundary. That is usually an Assess Only path, and the distinction is laid out in Assess Only versus full ATO.
• A system that is ready to operate but whose package is stuck in the approval chain. An IATT does not fix that and the AO will notice you are trying to use it as a bridge.
• Full operational test and evaluation on a deployed capability. That generally requires an ATO rather than an IATT, because you are past testing the system and into using it.

What Goes in the Request

An IATT package is smaller than a full authorization package, and the temptation is to treat it as a form. It is not a form. It is a risk decision, and the AO needs enough to make it. Build these in order:

1. Security categorization, completed per CNSSI 1253, with the confidentiality, integrity, and availability values stated. Even a short test needs a categorization to size the control set.
2. An authorization boundary diagram showing exactly what connects to what during the test, with the test boundary distinguished from the eventual operational boundary.
3. A test plan with specific objectives, a start date, a hard end date, the location, the data to be used, and the named test director. The end date is the line the AO reads first.
4. A statement of what data will be used and how it is handled, protected, and destroyed or sanitized at test completion. If the data is live, say so plainly and describe the protections.
5. Current vulnerability scan results and STIG compliance status for the systems in the test boundary, with any open CAT I findings called out and mitigated.
6. An implemented control set covering at least the controls that protect the operational environment from the system under test: access control, boundary protection, audit, and incident response.
7. A POA&M for anything not implemented, with remediation dates that fall inside or shortly after the test window.
8. A rollback and disconnect plan describing how the system comes off the network on the end date, who executes it, and how completion is confirmed.

The disconnect plan is the item that separates a fast approval from a slow one. The AO’s real fear is not the test. It is that the system quietly stays connected after the end date and becomes operational without anybody deciding it should. Give them the disconnect plan up front and you have answered the objection before it is raised.

How to Get One Fast

Speed on an IATT comes from removing reasons to send it back, not from escalating. The sequence that works:

1. Talk to the AO representative or SCA before you build anything. Ask what their office wants in an IATT package and whether the component has a local template. Thirty minutes here saves two weeks later.
2. Pick an end date that is defensible and shorter than you want. A 45-day request with a tight test plan approves faster than a 90-day request with a vague one, and a short IATT that finishes early looks better than an extension request.
3. Register the system and build the package in eMASS rather than emailing documents. The workflow gives the AO a record and gives you a submission date you can point to. The pre-flight items are the same ones in the eMASS package submission checklist.
4. Close or mitigate every CAT I before you submit. An open CAT I in a test boundary that touches the operational network is an automatic pause.
5. Brief the test director and the network owner on the same day you submit, so the Approval to Connect request and the IATT request move in parallel instead of in series.
6. Set your own calendar reminder for two weeks before expiration. You will need it.

Realistic timeline: a clean IATT package with an engaged AO representative moves in two to six weeks, which is faster than a full ATO but not fast enough to rescue a schedule you have already missed. For calibration against the full process, how long an ATO actually takes has the comparison.

What Kills IATT Requests

• No end date, or an end date described as at the conclusion of testing. The AO cannot accept an open-ended risk.
• A test plan that describes the capability rather than the test. Objectives, not features.
• Live data with no handling and sanitization statement.
• A boundary diagram that shows the operational architecture instead of the test architecture.
• An obvious attempt to use the IATT as a bridge to operations, usually visible because the test plan has no end state and the users named are operational users.

When It Expires

An IATT expires on its end date and it does not roll over. On that date the system comes off the operational network under your disconnect plan, and the test results feed the real authorization package. If testing is genuinely incomplete, you request an extension or a new IATT with a revised test plan explaining what changed, and you accept that the second request gets more scrutiny than the first.

The failure mode worth naming: a system running past its IATT end date is operating without authorization, and that is a reportable condition, not a paperwork lapse. The ISSO is the person who notices. Nobody else is watching that date, which is the quiet joke of the whole thing. You will spend a week assembling a risk package so somebody can plug a box into a network for six weeks, and then you will be the only person in the building who remembers when to unplug it.

If you want the full authorization sequence laid out so the IATT is a step in a plan rather than a scramble, the RMF Checklist covers what has to exist at each stage and when to start building it.