RMFInsider

eMASS permissions come from two things stacked together: the system role you are assigned on a specific system record (ISSO, ISSM, PM, SCA, AO, and a handful of others) and the organizational access your account holds within the eMASS instance (which organizations and sub-organizations you can even see). The system role decides what you can edit and which approval workflows you can act in. The organizational access decides which systems show up in your list at all. If you can see a system but cannot save a control implementation, you have the org access but not a writable system role. If you cannot find the system at all, you have the wrong org or no org.

That sounds simple, and it is, right up until an ISSM goes on leave with an approval sitting in a PAC workflow that only their role can advance, or a new ISSO discovers that the person who registered the system gave themselves the ISSO role and nobody else. I have watched a package sit for eleven business days because the one account with the right role was on a ship with no NIPR access.

The two layers: organizational access and system roles

Every eMASS instance (each Component and several large programs run their own) is carved into an organization tree. Your account is provisioned into one or more nodes of that tree by an eMASS administrator, usually called the eMASS Admin or Account Manager for that organization. That provisioning is what makes systems visible. It does not, by itself, let you edit anything.

Editing rights come from the Personnel tab on the individual system record. Someone with authority over that system (typically the ISSM, the PM, or the org eMASS admin) adds your account to the system and assigns one or more roles. You can hold different roles on different systems: ISSO on some, read-only on others.

If you are brand new, start with the beginner eMASS guide to get oriented on the screens before worrying about who can click what.

The roles you will actually see, and what each can do

Role names and exact permissions vary slightly by instance because each Component configures workflows differently, but the core set is consistent enough to describe with confidence.

ISSO (Information System Security Officer)

The workhorse role. The ISSO can edit the system details, categorization, the hardware and software lists, control implementation statements, test results, artifacts, and POA&M items. The ISSO can also initiate workflows: submit a package for review, submit a POA&M for approval, request a control inheritance. What the ISSO generally cannot do is approve anything in the Package Approval Chain (PAC) or Control Approval Chain (CAC) above their own step. You build, you submit, you wait. If the words “you wait” feel familiar, you are already an ISSO in spirit.

ISSM (Information System Security Manager)

The ISSM has everything the ISSO has plus approval authority at the ISSM step of the CAC and PAC. In practice the ISSM is the first person who can reject your work inside eMASS, which is useful: an ISSM rejection with comments is far cheaper than an SCA rejection two months later. The ISSM role also usually carries the ability to manage Personnel on the system, meaning the ISSM is who you ask when you need a new team member added. Read how the PAC and CAC approval chains work if the distinction between those two workflows is fuzzy, because roles map directly onto steps in each chain.

PM / IO (Program Manager / Information Owner)

The PM or Information Owner role is often a light-touch role: view the package, acknowledge risk, sometimes sign at a PAC step depending on the Component. Some instances give the PM edit rights over system details and the authorization boundary description. The PM matters for POA&Ms because the resource fields reflect program commitments.

SCA / SCAR (Security Control Assessor / Representative)

The SCA role is the assessor. It can enter and edit test results for assessment procedures, upload assessment artifacts (the SAR, the assessment plan, scan results), and approve or reject at the SCA step of the CAC and PAC. On some instances the SCA can also edit controls, but a good SCA will not touch your implementation statements; they assess them. If your SCA is editing your statements, ask why, politely, and then document it.

AO / AODR (Authorizing Official / Designated Representative)

The AO and AODR roles are approval roles at the top of the PAC. They review the risk recommendation from the SCA, review the residual risk, and issue the authorization decision. Editing rights are minimal by design. The AO does not fix your package. The AO decides whether to accept the risk of your package as it stands, and if the answer is no, it comes back down the chain.

System Administrator and other technical roles

Some Components define technical roles such as System Administrator, Network Administrator, or Privileged User for eMASS personnel records. These roles are usually view-plus-artifact roles: the sysadmin can see the controls they are responsible for, upload STIG checklists and scan evidence, and see POA&Ms assigned to them, but cannot change implementation statements or submit workflows. The person applying the STIG should upload the checklist and should not be able to mark CM-6 compliant.

Read-Only / View roles

Auditors, leadership, and adjacent ISSOs who need visibility for interconnections get read-only. Assign it generously; the risk is in people guessing, not reading.

How access is actually granted, step by step

The process differs a little by Component, but the sequence I have run new team members through looks like this:

• The new user completes the eMASS account request for the correct instance (Army, Navy, Air Force, DISA, and so on each run separate instances with separate request forms) and the required training, typically the eMASS Computer-Based Training and the annual Cyber Awareness Challenge.
• The user logs in with their CAC once so the account exists in the instance. Nothing can be assigned to an account that has never authenticated.
• The organizational eMASS admin adds the user to the correct organization node. Get the node exactly right; a user placed one level too high sees systems they should not, and one level too low sees nothing.
• The ISSM (or whoever holds Personnel rights on the system) opens the system record, goes to Personnel, adds the user, and assigns the role or roles. Save it, then have the user log out and back in.
• The user confirms they can see the system, open a control, and (for ISSO roles) save an edit. Do this test on day one, not the day the package is due.

Account inactivity is the silent killer here. eMASS instances disable accounts after a period of non-use, commonly 30 or 35 days, in line with the AC-2 inactivity requirements the instance itself has to meet. If your backup ISSO has not logged in since spring, they are not your backup ISSO anymore. Put a monthly login reminder on the calendar for anyone who holds a role but does not live in the tool.

Roles and the approval chains: where packages get stuck

Every workflow in eMASS is a chain of steps, and every step is tied to a role. When you submit a package, eMASS routes it to the next step and only accounts holding that step’s role on that system can act. This is where nearly every “my package is stuck” ticket I have fielded come from. The system is not broken. The role at the current step is either unassigned, assigned to someone who has left, or assigned to someone whose account got disabled for inactivity.

Before you submit anything, open Personnel and confirm that every step in the PAC and CAC has at least one active human behind it. I keep a one-line note per system: ISSO, ISSM, SCA, AODR, AO, each with a name and an alternate. The package submission walkthrough covers the full pre-submit sequence, and this personnel check is step zero of it.

The role mistakes I keep seeing

• One person, every role. A contractor registers the system and assigns themselves ISSO, ISSM, and PM to get through the initial build. It works, and then it becomes the permanent state. Separation of duties is a control you are supposed to be implementing (AC-5), not one you are supposed to be violating inside the tool that tracks your controls.
• Stale ISSM of record. The ISSM retires, transfers, or rotates, and the Personnel tab still lists them. The next PAC submission routes to a ghost. Update Personnel the same week a role holder leaves.
• No alternate for the SCA or AODR. These roles are often held by one person covering dozens of systems. Ask your Component whether an alternate can be designated. If not, plan submissions around their leave calendar. Yes, really.
• Giving sysadmins ISSO rights “so they can update their own controls.” Now your evidence and your assertion of compliance come from the same account. An assessor will notice, and rightly so.
• Wrong organization node. The user is on the system but cannot see it because their org access does not include the node where the system lives. Nine times out of ten this is the answer when a new user says eMASS is “empty.”
• Assuming roles transfer between systems. Being the ISSM on System A gives you nothing on System B. Each system record has its own Personnel list.

Registering a system: who gets what on day one

When you register a new system in eMASS, the person doing the registration typically ends up with an elevated role by default. Before you do anything else, populate Personnel properly: the real ISSM, the real ISSO (and an alternate), the PM, and the assigned SCA if you know who it is. Ask your org eMASS admin which AO and AODR accounts are attached to your organization so the PAC routes correctly.

Permissions are evidence too

Assessors look at eMASS Personnel as AC-2, AC-5, and AC-6 evidence. If one account authored the statements, entered the test results, and approved the POA&Ms, you have handed over a finding without anyone opening an artifact. For a deeper look at how all of these pieces fit into the full authorization lifecycle, the complete eMASS guide walks each module in order, and the roles described here are the thread running through all of them.

A quick self-check before your next submission

• Can I see the system, open a control, and save an edit? (Org access and system role both confirmed.)
• Does every PAC and CAC step have an active account with the correct role, plus an alternate where the Component allows one?
• Has every role holder logged in within the last 30 days?
• Is anyone holding a role they no longer need, or holding two roles that should be separated?
• Does the Personnel list match the roles named in the SSP and the ATO letter?

Five yes answers and your package will move at the speed of the humans in the chain instead of the speed of an account reactivation ticket. If you want that check, along with every other pre-submission item I run through before I let a package leave my hands, it is all laid out in the RMF Checklist, which I built precisely so I would stop learning these lessons one stuck package at a time.