Skip to main content

eMASS POA&M Fields: What Each One Means

by Jessica D. Miller · 8 min read · Navy RMF Field Guide

A field-by-field guide to the eMASS POA&M columns that matter most to Navy validators and authorizing officials. Know what to write and what to leave out.

Why POA&M Quality Determines ATO Outcomes

Authorizing Officials and validators read POA&Ms to assess organizational discipline and risk management credibility. A POA&M filled with generic entries, vague descriptions, and completion dates set two years in the future communicates that the organization copied control findings from an assessment tool without engaging with what remediation actually requires. That impression affects the AO's risk tolerance for the entire package.

A credible POA&M demonstrates that the organization understands each finding, has a realistic plan for addressing it, and has assigned the responsibility and resources to follow through. Quality in the POA&M does not guarantee an ATO, but poor quality in the POA&M can prevent one even when controls are substantially implemented.

The Fields That Matter Most

Weakness Name should map directly to a specific control identifier and finding. "Access Control Weakness" is not acceptable. "AC-2(1): Automated account management not implemented for privileged accounts in Active Directory" gives the validator exactly what they need to cross-reference against the SAR.

Weakness Description is a specific technical description of the gap — not a copy of the STIG rule title or control text. Describe what is actually observed: the system, the affected component, and the condition that creates the finding. Validators who see STIG titles pasted verbatim into this field treat the POA&M as unreviewed.

Source of Discovery must include the tool name and version, scan date, and assessment method. "ACAS scan" is insufficient. "ACAS 6.x vulnerability scan conducted 2026-09-15 by [organization]" provides the audit trail validators need to confirm the finding is current and properly attributed.

Status has four valid states: Open, Completed, On Hold, and Not Applicable. Open means active remediation work is underway or planned. Completed should only be used when remediation is verifiable — not when it is anticipated. On Hold requires a documented reason. Not Applicable requires technical justification, not just assertion.

Scheduled Completion Date must reflect actual organizational capacity. A date that is three months away when the remediation requires a procurement action, change control approval, and maintenance window scheduling is not credible. Validators flag unrealistic dates as evidence of weak program management. Build the date from a realistic work breakdown, not from a desired ATO date.

Milestones convert complex remediations into observable steps with individual completion dates. For a finding that requires a configuration change across 200 endpoints, milestones might include: develop configuration baseline, test in isolated environment, deploy to 25 percent of endpoints, complete full deployment. Milestones let validators and AOs track progress without requiring a package resubmission.

Risk Acceptance entries must identify who accepted the residual risk, at what authority level, and what specific risk was accepted. "Risk accepted" with no further detail is not an AO-acceptable entry. The entry should reference the signed risk acceptance memorandum and summarize the residual risk in one sentence.

Resources Required entries are often left blank, which is acceptable for findings remediable through configuration changes. For findings requiring procurement — endpoint detection tooling, hardware encryption modules, network segmentation infrastructure — documenting estimated staff hours and cost signals that the organization has a realistic remediation plan.

Common POA&M Mistakes

  • Pasting STIG rule titles verbatim as weakness descriptions without adding system-specific context
  • Setting all completion dates to the same future date, signaling batch entry rather than individual planning
  • Marking findings Completed without corresponding evidence artifacts uploaded to eMASS
  • Leaving risk acceptance fields blank for findings that have been On Hold for more than 90 days
  • Entering resources required as zero for findings that require tool procurement or infrastructure changes

What Validators Look For

Validators reviewing a POA&M focus on three questions: Is each finding specific enough to verify? Are the completion dates realistic given the remediation complexity? Does the pattern of findings reflect an organization that manages its security posture continuously, or one that discovered these gaps only during the assessment? A POA&M that answers all three questions credibly shortens the assessment cycle and reduces the probability of an additional round of validator correction requests.

The most effective POA&Ms are those built and maintained throughout the authorization lifecycle — not assembled in the weeks before package submission. Validators can distinguish between a living document and a document created to satisfy a submission requirement. The former produces faster authorization decisions.

Verified on current DISA and NIST guidance.


Frequently Asked Questions

How many open POA&M items will cause an AO to deny authorization?
There is no fixed threshold. AOs evaluate residual risk, not item count. Ten well-documented, low-risk items with credible milestones are more likely to support an ATO than three vague, high-risk items with no remediation plan. Risk acceptance by the appropriate authority is the mechanism for handling items that cannot be closed before authorization.
Can a finding be closed in eMASS before the scheduled completion date?
Yes. When remediation is complete and verifiable evidence is uploaded to eMASS, the finding can be marked Completed regardless of the original scheduled date. Updating the status promptly when findings are remediated keeps the POA&M accurate and reduces validator re-inquiry.
What evidence is required to close a STIG finding in eMASS?
Evidence requirements vary by finding type. Configuration-based findings typically require a screenshot or export from the configuration management system showing the compliant setting. Scan-based findings require a clean scan result showing the vulnerability is no longer present. Policy findings require the signed, dated policy document. Uploading evidence to the associated eMASS artifact record before marking the item Completed is required.

Work With Winston & Miller

Contact Us