Learning how to register a system in eMASS is the first hands-on task most new ISSOs face, and it’s the one with the least documentation to help you. eMASS — the Enterprise Mission Assurance Support Service — is the DoD’s system of record for RMF, and before you can implement a single control there, the system has to exist as a record with the right categorization, roles, and control set attached. Get the registration right and everything downstream flows; get it wrong and you’ll be redoing categorization and re-requesting permissions for weeks. Here’s the exact sequence and the decisions behind each field.
This assumes you already have an eMASS account and the basics of the tool. If eMASS itself is brand new to you, read eMASS for beginners first, then come back for the registration walkthrough.
Before You Register: Information and Roles You Need
Registration goes fast when you walk in with the answers already gathered. Don’t start clicking until you have:
- System identity: official system name, acronym, and a clear description of its mission and boundary — what’s in and what’s out.
- The people: who the System Owner, ISSM, ISSO, and Authorizing Official (AO) are. eMASS ties roles to real accounts, so you need names and, ideally, their eMASS user IDs.
- Categorization inputs: the information types the system processes and their confidentiality/integrity/availability impact levels (your FIPS 199 / CNSSI 1253 work).
- Overlays and baseline: which control baseline (Low/Moderate/High) and any overlays (privacy, classified, cloud, space) apply.
- DoD component and organization the system falls under, since that drives which eMASS instance and workflow you use.
Step 1: Create the System Record — Key Fields Explained
From the system registration workflow, you’ll populate the core record. The fields that matter most and trip people up:
| Field | What to enter / watch for |
|---|---|
| System Name & Acronym | Use the official name from the system’s charter, not a nickname — it appears on the ATO and can’t be casually changed later |
| System Type | Major Application, General Support System, enclave, etc. — this affects boundary and inheritance expectations |
| DoD Component / Organization | Determines routing and which AO chain the package flows to |
| Authorization boundary description | Be precise; a vague boundary invites assessor questions later and undermines your inheritance claims |
| System Life Cycle / Acquisition phase | Drives which activities eMASS expects next |
Step 2: Set Categorization and Select the Baseline/Overlay
This is the highest-stakes part of registration. You enter the confidentiality, integrity, and availability impact levels, and eMASS uses them to generate the control set. Choose the security control baseline that matches the categorization, then apply any overlays. The moment you confirm this, eMASS builds out the full list of controls the system must address — potentially hundreds of them.
Take the categorization seriously here because changing it after controls are populated and work has started is painful: assessment results, POA&M items, and implementation statements all key off that control set. A rushed “Moderate” that should have been “High” means re-tailoring the entire package. This is the same categorization decision that anchors the whole ATO process — in eMASS it just becomes concrete and hard to undo.
Step 3: Assign Roles and Request the Right Permissions
eMASS is role-driven. Each person who touches the package needs to be assigned to the system with the correct role — ISSO, ISSM, System Owner, SCA, AO — and each role carries specific permissions. As the ISSO you’re typically requesting the ISSO role on the system, which your ISSM or system admin approves. Assign roles deliberately: too little access and you can’t do your job; handing out broad permissions loosely is a finding waiting to happen.
Make sure the AO and SCA roles are mapped to the correct people early, even if they won’t act until later. Packages stall at the authorization step because the AO was never properly associated with the system in eMASS and can’t see it when it’s time to sign.
Step 4: Common Registration Mistakes That Cause Rework
- Wrong categorization. The single most expensive mistake — it regenerates your entire control set when corrected.
- Sloppy boundary description. A fuzzy boundary breaks your inheritance story and multiplies assessor questions.
- Duplicate system records. Someone already registered it under a slightly different name; always search before creating to avoid a duplicate package nobody maintains.
- Missing role assignments. The AO or SCA isn’t attached, so the package can’t move when it needs to.
- Unofficial system name. A nickname now becomes a mismatch between eMASS and the signed ATO later.
Don’t lose track of what comes after registration
Registration just creates the container — then come hundreds of controls, artifacts, and POA&M items. The RMF Checklist ($27) maps the whole sequence so nothing slips between registration and authorization.
What Happens Next
With the system registered, categorized, and roles assigned, eMASS now shows your populated control set. From here you move into implementation — documenting how each control is met, uploading artifacts, and eventually recording assessment results and POA&M items. Registration is the foundation everything else stacks on; the twenty minutes you spend getting the boundary and categorization right save you weeks of rework down the line. For the deeper mechanics of working the package day to day, the complete eMASS guide picks up where this leaves off.
Final Thoughts
Knowing how to register a system in eMASS is really about front-loading good decisions: an accurate boundary, a defensible categorization, the correct baseline and overlays, and clean role assignments. None of it is technically hard — it’s just unforgiving if you rush it. Walk in with your inputs gathered, populate the record deliberately, and you’ll have a clean foundation that carries the system all the way to an ATO.
Leave a Reply