Every engagement is keyed to a layer. Most advisory operates in the top two. The reason authorizations stall is usually somewhere in the bottom three.
Whether to pursue federal at all, and in what order.
Strategic direction for building a federal business: whether to pursue it at all, which agencies and programs to approach first, how to find and keep a sponsor, and what an authorization genuinely costs in engineering time rather than in consulting fees.
Translating NIST SP 800-53, FIPS, and Department of Defense policy into engineering work a team can schedule. The goal is that engineers understand why a requirement exists, not just that it was assigned to them.
Building the engineering culture, defaults, and controls that make an authorization a byproduct of how the team already works instead of a separate campaign run against a deadline.
The package, the assessor, the award.
Advisory across FedRAMP certification under the 2026 Consolidated Rules: choosing among Certification Classes A through D, meeting Key Security Indicators, structuring evidence, and preparing for assessment. We advise the team that owns the certification; we do not produce its artifacts or meet its ongoing requirements on its behalf.
Advisory for Department of Defense Impact Level 4 and Impact Level 5 authorization under the DoD Cloud Computing SRG: what the authorization asks of the system and the engineering team, how it differs from FedRAMP certification, and how to sequence the two. IL5 now requires CNSSI 1253, the National Security System designation, and we advise on meeting those controls.
Advisory on CNSSI 1253, the National Security System designation now required for Impact Level 5: which controls apply to a given system, and how to meet them in a running system rather than on paper.
Producing the customer-facing configuration guidance FedRAMP requires under SCG-CSO-RSC: how an agency securely accesses, configures, operates, and decommissions top-level administrative accounts, and what the settings only those accounts can reach actually do. Required of providers certified in Classes B, C, and D.
Choosing an independent assessor, and knowing what to ask before signing. Assessors differ in the architectures they have actually assessed, how they handle findings mid-assessment, their throughput, and whether they have worked at your certification class or Impact Level. REM5 does not perform assessments — we help you pick the organization that will.
Keeping an authorization alive after the award: continuous monitoring, significant change handling, vulnerability response within required timelines, and the reporting cadence that agencies and sponsors rely on.
This is the floor for most advisory engagements — the control matrix and the gap list. Everything below it is where the controls are actually met.
What the system actually looks like, and how it connects.
Designing connectivity that survives DoD Cloud Access Point and DISA connection review: boundary definition, CAP ingress and egress paths, and the network architecture decisions that are expensive to reverse once an authorization is underway.
Designing the integrations an Impact Level 5 service has to make with DoD enterprise infrastructure: DISA EEMSG, MILProxy — the DNS proxy for .mil domains — and the DoD NIC. Planned for early these are routine; discovered late they force architecture changes.
Zone signing, key generation and rotation, chain of trust to the parent zone, and resolver behavior under failure. Covers the operational practices that keep a signed zone from becoming an outage.
How code and keys become things you can prove claims about.
Building a supply chain you can make claims about: SBOM generation and consumption, build provenance and attestation, artifact signing and verification, dependency integrity, and the policy that decides what is allowed to ship. In DoD environments that extends to hardened base images and registries such as Iron Bank.
Advisory on meeting NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: signing key management and scoping, token verification and validity periods, and the identity provider and authorization server architecture behind single sign-on, federation, and API access.
Implementing FIPS to meet FedRAMP and Department of Defense requirements: selecting validated cryptographic modules, configuring the stack to use them, and resolving the libraries and third-party components that need work before they will run under FIPS.
Generating and maintaining System Security Plan content from live system state instead of by hand, so the documented system and the running system describe each other and stay that way between assessments.
What happens after it ships, on a schedule you can meet.
Applying and maintaining hardening baselines across the operating systems, containers, and services in scope: which benchmark or STIG applies to what, which deviations can be justified and how to document them, and keeping hardened images from drifting once they are running. We also advise on authoring new benchmarks and STIGs, and can help write them.
Meeting remediation timelines without a manual scramble: automated patch and image pipelines, vulnerability triage that distinguishes real exposure from scanner noise, and evidence that remediation happened when you said it did.