Atlas ApexAtlasApex

FedRAMP · Identity Lens

FedRAMP

FedRAMP makes identity the single most evidenced control area in your authorisation package — and the area auditors test hardest at continuous monitoring.

Full name
Federal Risk and Authorization Management Program
Region
United States federal government
Applies to
Cloud service providers selling to US federal agencies, and the agencies that consume those services. FedRAMP baselines (Low, Moderate, High) inherit from NIST SP 800-53.

FedRAMP standardises the security assessment and authorisation of cloud services for US federal use. The control baselines derive from NIST SP 800-53, with FedRAMP-specific parameters and additional requirements. The Access Control (AC) and Identification and Authentication (IA) families are the largest single sources of evidence in any FedRAMP package, and the area where continuous-monitoring deviations are most often found.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

AC family — Access control (NIST 800-53 / FedRAMP baselines)

Account management, access enforcement, separation of duties, least privilege, session control, remote access, and the AC-2 enhancements that govern automated account management, role-based control, and privileged account oversight. The bulk of the access-control evidence comes from the identity platform.

IA family — Identification and authentication

User identification, device authentication, identifier management, authenticator management, and the FedRAMP-mandated cryptographic strength for authenticators. FedRAMP High requires phishing-resistant authenticators (PIV / FIDO2) for privileged users.

AU family — Audit and accountability

Audit events, content, storage, review, analysis, and retention. Identity events are the largest audit-record source in most authorisations and the most-scrutinised at annual assessment.

FedRAMP continuous monitoring

Monthly scans, deviation reports, and significant-change requests. Identity-related changes (new federation trust, new privileged role, MFA policy change) are typically classified as significant and require pre-approval.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

Authenticator-strength requirements at High baseline interpreted loosely — phishing-resistant only for human admins, not for the privileged service accounts that hold the actual keys.

Shared service accounts used in production with no formal exception, no risk acceptance, and no rotation. Continuous monitoring deviation that ages for months.

Federation trust changes made by the cloud service provider's identity team without going through the FedRAMP significant-change process, leading to authorisation jeopardy.

Audit log content that meets the letter of AU-3 but cannot be used to reconstruct an incident — gaps in actor, target, and outcome fields surface during forensic review.

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

Identity architecture documented as the System Security Plan's foundational service, with explicit mapping of every AC/IA/AU control to its enforcement point in the identity platform.

Phishing-resistant MFA enforced for all federal users at FedRAMP High, including programmatic / API access using mTLS or workload identity instead of static secrets.

Significant-change governance integrated into the identity-change pipeline so a policy commit cannot ship to production without the FedRAMP gate.

Need a FedRAMP-ready identity baseline?

We start with an assessment that maps your identity controls to FedRAMP requirements, then design and operate the gaps.

Book a Conversation