1. Prerequisites — Before You Start
eMASS Account Access
Before you can register a system, you need an eMASS account.
IMPORTANT: Getting eMASS access can take weeks. Start this process immediately.
| Requirement | Details |
|---|---|
| CAC/PKI | DoD PKI certificate on ECA medium or Common Access Card (CAC) |
| Training | Complete the DoD Cyber Awareness Challenge |
| eMASS URL | NISP: https://emass-nisp.csd.disa.mil/ (CAC required) |
| Role | IAM (Information Assurance Manager) role for system registration |
| CAGE Code | Your organization must have an assigned CAGE code under DCSA |
| Account Guide | NISP eMASS User Account Request Guide v3 |
Key Personnel Required
Identify these people before starting — their names go into eMASS registration.
| Role | Responsibility |
|---|---|
| System Owner | Ultimately responsible for the system's security posture |
| ISSM | Information Systems Security Manager — manages the RMF package |
| ISSO | Information Systems Security Officer — day-to-day security operations |
| AO | Authorizing Official — makes the risk-based ATO decision |
| SCA | Security Controls Assessor — independently evaluates controls |
2. The 7 RMF Steps (NIST 800-37 Rev 2)
The Risk Management Framework is a 7-step process. Click each step's circle to mark it complete.
0
PREPARE
- Establish risk management strategy — Document in SSP
- Define authorization boundary — SRE platform + CI/CD tools
- Register system in eMASS — See Section 3
- Identify key roles (SO, ISSO, ISSM, AO, SCA) — Fill in names
- Identify common controls for inheritance — See Section 5
1
CATEGORIZE
SRE Categorization: SC = {(C, MODERATE), (I, MODERATE), (A, MODERATE)}
- FIPS 199 classification (C-I-A levels) — DONE Moderate-Moderate-Moderate
- NIST SP 800-60 information types — DONE
- Document categorization justification — DONE
2
SELECT
- Select NIST 800-53 Rev 5 control baseline — Moderate (~325 controls)
- Apply DoD overlays (CNSSI 1253) — Apply during eMASS registration
- Tailor controls (scope, compensating) — During eMASS control management
- Identify inheritable controls — ~40-60% can be inherited
3
IMPLEMENT
- Implement selected controls — DONE 47 controls mapped to platform components
- Document implementation in SSP — PARTIAL OSCAL SSP exists, needs eMASS format
- Map controls to components — DONE
4
ASSESS
- Independent SCA evaluates controls — TO DO
- Each control rated: Compliant / Non-Compliant / N/A
- Security Assessment Report (SAR) produced by SCA
- Non-compliant findings entered into POA&M — TEMPLATE READY
5
AUTHORIZE
- AO reviews SSP + SAR + POA&M
- AO issues: ATO, DATO, or IATT
- Authorization document uploaded to eMASS
6
MONITOR
- Continuous monitoring per ISCM plan — DONE Prometheus, Grafana, NeuVector
- Ongoing vulnerability scanning — DONE Trivy, NeuVector, Kyverno
- POA&M updates — TEMPLATE READY
- Quarterly reviews — TEMPLATES READY QREV 1-7
3. eMASS Registration — Step by Step
Registration in eMASS has 5 sub-steps. Here is exactly what to enter.
Registration Step 1: System Profile
| Field | What to Enter |
|---|---|
| System Name | Secure Runtime Environment Platform |
| System Acronym | SRE |
| System Type | IS Enclave (required — DSS-specific types are not available in eMASS) |
| DITPR ID | [Your DITPR registration ID] |
System Description (copy-paste into eMASS)
A Kubernetes-based DevSecOps platform providing a hardened, compliant runtime for deploying containerized applications. Built on RKE2 with FIPS 140-2 compliance, DISA STIG hardening, and all 8 RAISE 2.0 security gates implemented in the CI/CD pipeline. The platform provides inheritable security controls for hosted applications under RAISE RPOC designation.
Authorization Boundary (copy-paste into eMASS)
The SRE platform including: RKE2 Kubernetes cluster, Flux CD GitOps engine, Istio service mesh, Kyverno policy engine, Harbor container registry, CI/CD pipeline tools (Semgrep, Syft, Gitleaks, Trivy, OWASP ZAP, Cosign), monitoring stack (Prometheus, Grafana, Loki, Tempo), secrets management (OpenBao, ESO), runtime security (NeuVector), identity provider (Keycloak), and backup (Velero). Does NOT include the hosted tenant applications themselves — each application has its own RMF package.
Registration Step 2a: Security Impact Levels
| Security Objective | Impact Level | Justification |
|---|---|---|
| Confidentiality | MODERATE | Platform hosts CUI. Unauthorized disclosure could have serious adverse effects on organizational operations. |
| Integrity | MODERATE | Unauthorized modification of platform configuration or application deployments could have serious adverse effects on mission operations. |
| Availability | MODERATE | Disruption of platform services could have serious adverse effects but would not cause catastrophic mission failure. |
eMASS will auto-populate the NIST 800-53 Moderate baseline (~325 controls) based on these selections.
Registration Step 2b: Manage Controls
After the baseline is populated, mark each control:
| Action | When |
|---|---|
| Applicable | Control is implemented by the SRE platform |
| Not Applicable | Control does not apply (document justification) |
| Inherited | Control is satisfied by infrastructure provider (cloud, physical facility) |
TIP: Start with inherited controls first — this immediately reduces your workload by 40-60%.
For each Applicable control, you will need to enter:
- Implementation description (how the control is met)
- Responsible entity (who maintains it)
- Evidence/artifacts
Registration Step 3: Inheritance
Link to your infrastructure provider's authorization:
- If on AWS GovCloud: Link to AWS FedRAMP authorization
- If on-premises: Link to the facility's physical security authorization
- The SRE platform itself becomes a Common Control Provider (CCP) for tenant apps
Registration Step 4: Assign Roles
| Role | Name | |
|---|---|---|
| System Owner | _________________ | _________________ |
| ISSM | _________________ | _________________ |
| ISSO | _________________ | _________________ |
Registration Step 5: Review and Submit
- Review all entered information
- Verify all required fields (marked with red stars) are complete
- Click "Submit System" to complete registration
- System appears in available systems list
4. ATO Package — Required Documents
The "Big Three" (Required)
| # | Document | Description | Status |
|---|---|---|---|
| 1 | System Security Plan (SSP) | System description, boundary, architecture, complete control implementation descriptions | PARTIAL |
| 2 | Security Assessment Report (SAR) | Results of independent control assessment by SCA | TO DO |
| 3 | Plan of Action & Milestones (POA&M) | Response to each SAR finding with remediation plan | TEMPLATE |
Supporting Documents
| # | Document | Description | Status |
|---|---|---|---|
| 4 | Risk Assessment Report (RAR) | Identifies risks, likelihood, impact, mitigation | TO DO |
| 5 | Authorization Boundary Diagram | Architecture diagrams (DoDAF OV-1, SV-6 recommended) | PARTIAL |
| 6 | Hardware/Software List | Inventory of all components with versions | DONE |
| 7 | PPSM Registration | All ports/protocols registered per DoDI 8551.01 | PARTIAL |
| 8 | Network Architecture Diagram | Data flows, interfaces, external connections | TO DO |
| 9 | Contingency Plan | Disaster recovery procedures | PARTIAL |
| 10 | Incident Response Plan | Per DAAPM Appendix Q requirements | TO DO |
| 11 | Configuration Management Plan | How changes are controlled | DONE |
| 12 | Continuous Monitoring Plan | ISCM strategy | DONE |
| 13 | Privacy Impact Assessment (PIA) | If PII is processed | DONE |
| 14 | Interconnection Security Agreements | For external system connections | IF APPLICABLE |
What the SSP Must Contain
The SSP is built IN eMASS (no longer a separate Word document). For each control, enter the following format:
Control: AC-2 Account Management
Implementation Status: Implemented
Implementation Description:
Account management is handled by Keycloak (v24.8.1) as the centralized
identity provider. All platform access requires SSO authentication via OIDC.
User accounts are organized into groups (sre-admins, sre-viewers, developers)
mapped to Kubernetes RBAC ClusterRoles. Account creation requires approval
from the platform ISSM. Deprovisioning is automated when users are removed
from Keycloak groups.
Responsible Entity: Platform Team
Evidence: Keycloak configuration export, RBAC role definitions, account audit log
5. Control Inheritance — Reducing Your Workload
This is the most important optimization. A Moderate baseline has ~325 controls. You do NOT implement all of them from scratch.
Inheritance Sources
| Source | Controls Inherited | Examples |
|---|---|---|
| Cloud Provider (FedRAMP) | ~100-130 controls | PE (Physical), some AC, some SC, some MP |
| Facility Security | ~20-30 controls | PE-1 through PE-20 (physical access, environmental) |
| Existing Network Authorization | ~15-20 controls | Network-layer SC controls |
Controls SRE Implements Directly
After inheritance, SRE implements ~120-150 controls across these families:
| Family | # Controls | Primary SRE Components |
|---|---|---|
| AC (Access Control) | ~18 | Keycloak, Kubernetes RBAC, Istio, Kyverno |
| AU (Audit) | ~12 | Loki, Prometheus, K8s audit log, OpenBao audit |
| CA (Assessment) | ~8 | Kyverno PolicyReports, NeuVector, compliance scanner |
| CM (Configuration Mgmt) | ~12 | Flux CD (GitOps), Kyverno, Ansible STIGs |
| IA (Identification/Auth) | ~10 | Keycloak, Istio mTLS, cert-manager, OpenBao |
| IR (Incident Response) | ~8 | AlertManager, NeuVector, Grafana alerting |
| RA (Risk Assessment) | ~6 | Trivy, NeuVector, Kyverno violation reports |
| SA (System Acquisition) | ~10 | SBOM (Syft), Cosign, Harbor, CI/CD pipeline |
| SC (System/Comms) | ~15 | Istio mTLS, FIPS crypto, TLS, NetworkPolicies |
| SI (System Integrity) | ~12 | NeuVector, Cosign signing, Kyverno admission |
SRE as Common Control Provider (CCP)
Once SRE has an ATO, tenant applications inherit YOUR controls. This is the whole point of RPOC — apps deploy faster because they inherit your controls.
Tenant App inherits from SRE RPOC:
- SC-8 (Transmission Confidentiality) -> Istio mTLS
- CM-7 (Least Functionality) -> Kyverno policies
- SI-7 (Software Integrity) -> Cosign + Kyverno verification
- AU-2 (Audit Events) -> Loki + Prometheus
- RA-5 (Vulnerability Scanning) -> Trivy + NeuVector
- AC-4 (Information Flow Enforcement) -> NetworkPolicies + Istio
... and ~40 more controls
6. eMASS Control Validation
Validating security controls in eMASS is a 3-step process.
Step 1: Test Assessment Procedures
- All Assessment Procedures (APs/CCIs) assigned to each control must be tested
- Results recorded per AP: Satisfied, Other Than Satisfied, Not Applicable
Step 2: Industry/Organization Review
- ISSO/ISSM reviews the package
- Verifies all controls have implementation descriptions
- Verifies evidence is attached
- Submits to SCA
Step 3: SCA Validation
- Independent SCA reviews and validates each control
- Issues SAR with findings
- Non-compliant controls go to POA&M
Uploading Evidence
- Click "Add Artifact" per control/AP association
- Upload individual files or .zip bundles (use
isBulk=truefor bulk) - Category defaults to "Evidence"
- eMASS supports bulk export/import of CCI test results via templates
7. Automation — SAF CLI & eMASS API
The MITRE Security Automation Framework (SAF) CLI integrates with the eMASS REST API, enabling automated evidence upload from your CI/CD pipeline.
SAF CLI (eMASS Integration)
GitHub: mitre/saf and mitre/emass_client
Available API endpoints:
| Endpoint | Capabilities |
|---|---|
| Controls | View, add, update control implementation descriptions |
| Test Results | View, add test results for assessment procedures |
| Artifacts | View, add, update, remove evidence artifacts |
| POA&M | View, add, update POA&M items |
| System | View system details |
Automated Evidence Pipeline
CI/CD Pipeline produces artifacts
|
+-- Semgrep SARIF --> SAF CLI --> eMASS (SA-11 evidence)
+-- Trivy SARIF --> SAF CLI --> eMASS (RA-5 evidence)
+-- Gitleaks JSON --> SAF CLI --> eMASS (IA-5 evidence)
+-- SBOM (SPDX) --> SAF CLI --> eMASS (CM-8 evidence)
+-- Cosign verify --> SAF CLI --> eMASS (SI-7 evidence)
+-- Kyverno reports --> SAF CLI --> eMASS (CM-7 evidence)
+-- NeuVector scans --> SAF CLI --> eMASS (SI-4 evidence)
OSCAL Integration
OSCAL (Open Security Controls Assessment Language) is the machine-readable format for compliance:
- FedRAMP will require OSCAL after September 2026
- DoD is moving in the same direction
- SRE already has an OSCAL SSP at
compliance/oscal/ssp.json - FedRAMP OSCAL Resources and Templates
8. Timeline & Cost Expectations
| Metric | Typical | With DevSecOps / cATO |
|---|---|---|
| Timeline | 12-18 months | 6-9 months |
| Cost | $1M-$3M+ | Reduced via automation |
| Control burden | ~325 (Moderate) | ~120-150 after inheritance |
Key Milestones
| Milestone | Target |
|---|---|
| Get eMASS access | Week 1-3 |
| Register system | Week 3-4 |
| Complete SSP (control descriptions) | Week 4-12 |
| Submit to SCA (90 days before need) | Week 12 |
| SCA assessment | Week 12-20 |
| Remediate findings, update POA&M | Week 20-24 |
| AO review and decision | Week 24-28 |
| RPOC designation (after ATO) | Week 28-30 |
DCSA recommends: Submit complete security plan at least 90 days before need date.
9. Practitioner Tips
DO
- Start eMASS access NOW — account creation takes weeks
- Define a narrow authorization boundary — include only what is essential
- Maximize control inheritance — inherit from cloud provider FedRAMP, facility security, network authorization (40-60% of Moderate controls)
- Automate evidence collection — use SAF CLI, OSCAL, pipeline-generated artifacts
- Use OSCAL format — machine-readable compliance artifacts will be required soon
- Submit 90+ days early — DCSA needs time for thorough review
- Register in DITPR first — you will need the DITPR ID for eMASS registration
- Register ports in PPSM — all ports/protocols must be registered per DoDI 8551.01
- Pursue cATO if your system supports it — your DevSecOps pipeline makes you a strong candidate
DO NOT
- Attempt all ~325 controls from scratch — leverage inheritance aggressively
- Submit incomplete packages — #1 cause of delays and rejections
- Default to legacy RMF — pursue cATO with your DevSecOps pipeline
- Forget the PPSM registration — commonly missed, causes delays
- Wait until the end to engage the AO — keep them informed throughout
- Ignore the POA&M — overdue items are the second biggest cause of ATO denial
10. Reference Documents
eMASS Guides
NISP eMASS Industry Operation Guide v1.1
Complete eMASS operations guide for NISP industry users
DCSA
NISP eMASS Job Aid
Quick-reference job aid for eMASS tasks
DCSA
eMASS Step-by-Step Instructions
Detailed walkthrough of eMASS registration steps
DISA
NISP eMASS Account Request Guide v3
How to request your eMASS user account
DCSA
DCSA A&A Process Manual (DAAPM) v2.2
The authoritative guide for DCSA assessment and authorization
DCSA
RMF & NIST Standards
NIST SP 800-37 Rev 2
Risk Management Framework for Information Systems
NIST
NIST SP 800-53 Rev 5
Security and Privacy Controls for Information Systems
NIST
FIPS 199
Standards for Security Categorization
NIST
NIST SP 800-60
Guide for Mapping Types of Information to Security Categories
NIST
DoD DevSecOps & cATO
DoD cATO Implementation Guide
Continuous Authorization to Operate guidance
DoD CIO
cATO Evaluation Criteria
Criteria for evaluating cATO readiness
DoD CIO
DoD DevSecOps Reference Design v2.0
Reference architecture for DoD DevSecOps pipelines
DoD CIO
DoD Cybersecurity Reciprocity Playbook
Guidance on authorization reciprocity across DoD
DoD CIO
Automation Tools
MITRE SAF CLI
Security Automation Framework with eMASS integration
GitHub
MITRE eMASS Client API
Ruby/Node client library for eMASS REST API
GitHub
FedRAMP OSCAL Templates
Official OSCAL resources and SSP templates
FedRAMP
DISA PPSM Resources
Ports, Protocols, and Services Management
Cyber.mil
Helpful Articles
What is Required in an ATO Package
Practical guide to assembling your ATO documentation
Rise8
How Long Does the ATO Process Take
Timeline expectations and how to accelerate
Rise8
ATO Checklist
Step-by-step checklist for ATO readiness
Rise8
7 Common Mistakes in DoD ATO
Costly pitfalls to avoid in the authorization process
Second Front
Maximize Control Inheritance
Guide to reducing your NIST 800-53 workload through inheritance
Second Front
Quick Start Checklist
Track your immediate next steps. Progress is saved automatically in your browser.
- Get eMASS account — Request CAC/PKI access, complete Cyber Awareness training
- Identify key personnel — System Owner, ISSM, ISSO, AO, SCA
- Register in DITPR — Get DITPR ID before eMASS registration
- Register in eMASS — Use the Step 1-5 guide above
- Register ports in PPSM — Per DoDI 8551.01
- Complete control descriptions — Map each NIST 800-53 control to SRE components
- Identify inherited controls — Link to cloud provider / facility authorizations
- Create authorization boundary diagram — Formal DoDAF diagram
- Create incident response plan — Per DAAPM Appendix Q
- Submit CI/CD Tools Certification — To Technical Authority
- Schedule SCA assessment — 90 days before target ATO date
- Engage AO early — Brief them on the platform and RPOC intent