Cloud-Native Apps: FedRAMP, CMMC, NIST

Federal cloud programs frequently wrestle with the same question: if a system needs to satisfy FedRAMP High, CMMC Level 2, and NIST SP 800-53, does that mean three separate compliance tracks running in parallel? In practice, these frameworks share an enormous amount of control overlap. An application architected deliberately for compliance can satisfy all three simultaneously — not by running parallel audits, but by treating the shared control set as the architectural baseline.

This covers the cloud-native architecture patterns Rutagon applies to build government applications that ship compliant, not just compliant enough to pass a point-in-time audit.

Control Family Overlap Across FedRAMP, CMMC, and NIST

The control overlap is significant:

FedRAMP High is based on NIST SP 800-53 Rev 5 — it adds parameter values and required documentation atop the NIST baseline
CMMC Level 2 maps to NIST SP 800-171 Rev 2, which is itself derived from NIST 800-53
All three share control families: access control (AC), audit and accountability (AU), configuration management (CM), identification and authentication (IA), incident response (IR), and system and communications protection (SC)

For a cloud-native application addressing all three frameworks, the practical approach is:

Implement NIST 800-53 Rev 5 at FedRAMP High control strength (the most demanding baseline)
Map each implemented control to its CMMC equivalent
Produce evidence artifacts that satisfy all three assessment procedures simultaneously

The result: one set of controls, one set of evidence, multiple compliance authorizations.

Access Control as Architecture

AC-2 (Account Management), AC-3 (Access Enforcement), and AC-6 (Least Privilege) appear in all three frameworks and impose the same core requirement: users and systems should have exactly the access they need and no more. Access should be documented, audited, and revokable.

Cloud-native implementation:

Infrastructure layer: IAM roles with policy conditions limiting access to specific resources, regions, and time windows. No wildcard resource ARNs (*) in production policies. IRSA for pod-level access without stored credentials.

Application layer: RBAC enforced at the API layer. Every endpoint carries an authorization check — not just authentication. Role assignments stored in a governable data store (not hardcoded in application code).

Network layer: Security group rules restricted to specific source CIDR ranges or security group IDs. No 0.0.0.0/0 ingress for production services. VPC flow logs enabled and ingested by the ConMon pipeline.

Evidence for auditors: IAM policy JSON, Kubernetes RBAC manifests, and application RBAC configuration are version-controlled and constitute auditable access control documentation. The "show me your access control documentation" question is answered with a git log and the current policy set.

Audit Logging Architecture

AU-2 (Auditable Events), AU-3 (Content of Audit Records), and AU-12 (Audit Record Generation) are among the most documentation-intensive controls in all three frameworks. They require that specific event types are logged, that logs contain specific fields (who, what, when, where, outcome), and that logs are protected and retained.

Cloud-native audit logging architecture:

Application layer: Structured JSON logging (not free-text) with mandatory fields: timestamp (ISO 8601), user_id, request_id, action, resource_id, outcome (success/fail), ip_source. Every authentication event, access decision, and privileged action generates a log entry.

Infrastructure layer: CloudTrail captures all AWS API calls — management events, data events (S3 object access, Secrets Manager reads). GuardDuty ingests these trails for threat detection. CloudTrail logs are shipped to a write-once S3 bucket in a separate security account with Object Lock enabled — protection from tampering.

Kubernetes layer: Kubernetes API audit logging captures all API server interactions. These logs are shipped to CloudWatch and retained per the program's AU-11 (Audit Record Retention) requirement (typically 3 years for FedRAMP High programs).

Immutable log pipeline: Logs flow to a centralized account that the application accounts cannot modify — a security control preventing a compromised workload account from deleting its own audit trail.

Configuration Management: Infrastructure as Code as CM Policy

CM-2 (Baseline Configuration), CM-3 (Configuration Change Control), and CM-6 (Configuration Settings) require documented baselines, change control processes, and enforcement of configuration settings.

Cloud-native implementation: infrastructure as code is the configuration baseline. The Terraform or CloudFormation state represents the authoritative baseline. Any drift from that state is detected by AWS Config and triggers a ConMon alert.

Change control: All infrastructure changes go through pull request review with required approvals from designated personnel. The PR is the change record — it captures who proposed the change, who reviewed it, when it was approved, and what was changed. No out-of-band changes (console clicks, direct API calls) are permitted in production accounts. SCPs (Service Control Policies) at the organization level block IAM actions that would allow bypassing the IaC pipeline.

STIG compliance: CIS Benchmarks and DISA STIGs are applied as automated policy checks (AWS Security Hub, Prowler, or custom Config rules). Failed checks create ConMon findings. Checks run on every infrastructure deployment, not just on periodic scans.

Encryption at Rest and in Transit

SC-8 (Transmission Confidentiality and Integrity) and SC-28 (Protection of Information at Rest) are satisfied through:

In transit: TLS 1.2 minimum enforced at the load balancer and API gateway. Internal service-to-service traffic encrypted via Istio mTLS. TLS policy rejects SSLv3, TLS 1.0, and TLS 1.1 connections.

At rest: All S3 buckets encrypted with KMS CMKs. RDS and DynamoDB instances use KMS encryption. EBS volumes on EC2 instances encrypted. KMS CMK policies restrict key usage to specific IAM roles with logging for all uses.

Key rotation: KMS CMK automatic rotation enabled (annual rotation for symmetric keys). Rotation events are recorded in CloudTrail.

Container Security as CM Baseline

Containers are software artifacts with version, configuration, and a defined security baseline. For FedRAMP and CMMC programs, containers are treated as baseline-governed artifacts:

Iron Bank base images define the approved OS and runtime baseline
Application containers are built from Iron Bank bases with pinned dependency versions
Container images are signed (AWS Signer) before deployment
EKS admission controllers reject unsigned or unauthorized images at the cluster level
Container scans (Trivy) are part of the CI pipeline — failed scans block deployment

Frequently Asked Questions

Can a single cloud application satisfy FedRAMP, CMMC, and NIST simultaneously?

Yes. The control families are substantially overlapping — FedRAMP High is built on NIST 800-53, and CMMC Level 2 maps to NIST 800-171 which shares significant DNA with 800-53. An application engineered to FedRAMP High control strength, with documented evidence artifacts, can satisfy all three frameworks with one control implementation and one evidence set. The key is mapping controls explicitly to each framework's assessment language in the SSP.

What does "compliance baked in" mean for cloud-native applications?

Compliance baked in means the engineering choices that satisfy compliance controls — structured audit logging, IaC-managed baselines, short-lived credentials, encrypted storage, container scanning in CI — are part of the standard engineering process, not a post-deployment audit preparation exercise. The compliance evidence is generated by the production system as a natural byproduct of how it operates.

How do you handle the FedRAMP ATO documentation burden?

FedRAMP High requires a system security plan (SSP), control implementation narratives for all ~450 controls, continuous monitoring deliverables, and boundary documentation. Rutagon manages this through a combination of parameterized SSP templates (most control narratives are reusable across programs with environment-specific parameters), automated ConMon evidence collection from the CI/CD pipeline, and quarterly deliverable automation. The goal is turning what's normally a 6-month ATO sprint into a continuous, low-overhead process.

How long does it take to achieve FedRAMP High authorization?

With a well-architected cloud-native application and complete documentation, FedRAMP High authorization typically takes 12–18 months through the traditional JAB process. Program-specific ATOs (P-ATO) issued by agency authorizing officials can move faster if the agency has existing approved baselines the new system can inherit. Rutagon's approach to ATO acceleration focuses on complete, well-organized documentation packages and proactive 3PAO engagement — not shortcuts.

What is the relationship between CMMC and FedRAMP for a contractor holding both?

For a contractor operating systems that handle both CUI (requiring CMMC) and federal agency data (potentially requiring FedRAMP), there's significant overlap but the two authorizations are separate. CMMC is assessed by C3PAOs for contractor systems; FedRAMP authorizes cloud services used by federal agencies. If you're a contractor whose cloud service is used by federal agencies, you may need both. Rutagon can help map the control set to satisfy both frameworks with a unified evidence structure.