FedRAMP LI-SaaS vs Moderate: eligibility, controls, and real costs
Sienna VanceApril 29, 2026
Key takeaways
FedRAMP LI-SaaS covers 37 security controls, not 125. The 125 figure refers to FedRAMP Low. LI-SaaS is a further reduction, applicable only to SaaS products that do not store federal data on CSP-managed infrastructure.
LI-SaaS eligibility requires that federal data not be stored or processed by the CSP. If the SaaS product aggregates, logs, or transmits federal user data in any persistent form, it does not qualify -- regardless of data sensitivity.
Self-attestation under LI-SaaS shifts risk acceptance to the sponsoring agency. Agencies with mature ISSOs reject LI-SaaS submissions more frequently than most CSPs anticipate. One rejection forces a restart on a Moderate path with no credit for prior LI-SaaS work.
35% of authorized LI-SaaS environments drift out of compliance within six months, according to Vulnox research. The same CA-7 ConMon obligations that trip up Moderate CSPs apply at LI-SaaS -- the control set is smaller, the monitoring cadence is not.
A SaaS product designed for LI-SaaS can be disqualified by a single integration. Connecting to a federal agency system that returns CUI in API responses, even in a passthrough pattern, crosses the data storage threshold in most agency interpretations.
FedRAMP Moderate takes 12 to 18 months to initial ATO. LI-SaaS takes 6 to 9 months. The gap narrows when agency review cycles are included. Agencies are slower to accept LI-SaaS packages than the authorization timeline suggests.
TL;DR
LI-SaaS is not a lighter version of FedRAMP Moderate. It is a separate authorization pathway for a specific class of SaaS products that do not store federal data. Most CSPs that pursue it either qualify comfortably or discover at agency review that their product does not qualify at all. The middle path -- products that nearly qualify -- is where the real cost is. This guide maps the eligibility boundary precisely, explains what self-attestation means for regulatory exposure, and identifies the compliance failure modes specific to the LI-SaaS pathway.
The integration that disqualified the authorization
A project management SaaS company completed a nine-month LI-SaaS authorization effort. The product was a collaboration tool with no persistent storage of federal data on the CSP side -- users authenticated, created tasks, and the data lived in the agency's own infrastructure. It looked clean. During agency ISSO review, the reviewer asked about audit log retention. The application logged task creation events including the federal user's email address and agency identifier. Logs were retained for 90 days on the CSP's infrastructure. That is federal PII stored on CSP infrastructure. The agency rejected the LI-SaaS package. Nine months of work, $180,000 in assessment and preparation costs, and the CSP restarted on a Moderate path.
The product team knew about the audit logs. They did not know that audit logs containing federal user identifiers counted as federal data storage for LI-SaaS eligibility purposes. The eligibility standard is not about intent. It is about what the system actually holds.
What LI-SaaS eligibility actually requires
FedRAMP LI-SaaS was introduced to create a viable federal authorization pathway for SaaS products that function as productivity tools -- collaboration platforms, document editors, scheduling applications -- where the CSP provides the software layer but does not store or process federal agency data independently. The eligibility criteria have three components. First, the CSP cannot store federal data. This means no persistent storage of data generated by or about federal users on CSP-managed infrastructure, including logs, caches, backups, and analytics databases. Second, the application cannot process data above the Low impact level. Third, no additional software or hardware is required at the agency -- the service must function as delivered without customization that could introduce new data flows.
Example
The storage criterion is where most eligibility determinations fail. CSPs interpret 'federal data' narrowly -- structured records containing CUI or PII. Agencies interpret it more broadly -- any data that is generated in the context of a federal user's interaction with the system. Audit logs, session metadata, error logs that capture request payloads, and analytics event streams that include user identifiers all qualify as federal data under most agency ISSO interpretations. A SaaS product with a clean data model can fail LI-SaaS eligibility on its logging infrastructure alone.
The FedRAMP LI-SaaS control baseline covers 37 controls drawn from NIST 800-53. These are not a random 37 -- they are the controls that address the residual risk after assuming the CSP has no independent federal data exposure. The controls focus on access management, configuration integrity, and incident reporting. The absence of controls from AU (Audit and Accountability) reflects the assumption that the CSP has no federal data to audit. If a CSP's actual implementation contradicts that assumption, the entire control baseline is miscalibrated.
What assessment data shows about LI-SaaS in practice
Assessment base: Vulnox assessment and gap analysis data, 2024, across CSP environments pursuing FedRAMP LI-SaaS authorization
35% compliance drift within six months
Vulnox research shows 35% of authorized LI-SaaS environments drift out of compliance within six months of receiving their ATO. The pattern mirrors what Vulnox observes in Moderate environments: authorization creates a compliance peak, and what follows is entropy. For LI-SaaS specifically, the most common drift mechanism is product feature expansion. A new integration is added. A new analytics capability is enabled. User data that was not previously stored begins accumulating in a new database table. The change is not processed through the SSP update procedure. The authorization package no longer describes the actual system.
LI-SaaS authorization is not a stable state. It requires the same change management discipline as Moderate authorization for a different reason -- not because the control set is complex, but because the eligibility boundary is fragile. Any product change that touches data storage, data transmission, or integration scope needs to be evaluated against LI-SaaS eligibility criteria before deployment.
Istio sidecar injection gaps at the transport layer
Across Vulnox assessments of LI-SaaS environments built on Kubernetes, missed Istio sidecar injection creates plaintext microservice-to-microservice communication. The system security plan documents encryption in transit. The SSP is accurate at the application layer. At the service mesh layer, traffic between pods is unencrypted because the sidecar was not injected into one or more namespaces during a deployment. Standard vulnerability scanners do not inspect service mesh traffic patterns. The finding surfaces during manual penetration testing.
SC-8 (Transmission Confidentiality and Integrity) applies at LI-SaaS even with the reduced control set. A finding on SC-8 in a LI-SaaS package is not a minor gap -- it directly contradicts the CSP's attestation. Agencies that discover SC-8 failures post-authorization treat them as self-attestation inaccuracies, which carries different regulatory weight than a standard compliance finding.
Agency ISSO rejection rates underestimated at scoping
CSPs pursuing LI-SaaS authorization consistently scope their timelines against the technical authorization process: control implementation, documentation, self-attestation package preparation. They do not adequately scope for agency review cycles. Agencies with experienced ISSOs are more rigorous about LI-SaaS eligibility review than about Moderate 3PAO packages, because self-attestation transfers risk to the agency. A rejection at agency review -- which can occur months after the technical authorization package is complete -- requires restarting on a Moderate path with no carryover credit for prior work.
The 6 to 9 month timeline cited for LI-SaaS authorization is the technical authorization timeline. It does not include agency review cycles, which vary by agency from 30 days to over six months. CSPs that have experienced Moderate 3PAO assessment delays often assume LI-SaaS's self-attestation model will be faster end-to-end. It is faster technically. It is not faster when the agency review cycle is included.
RA-5(4) implementation errors specific to reduced-scope environments
FedRAMP parameter RA-5(4) requires vulnerability scanning of privileged access paths. In LI-SaaS environments, privileged access is typically narrower than in Moderate deployments -- fewer administrators, tighter scope. CSPs interpret this as a lower scanning burden and implement quarterly scans against a narrow target list. The FedRAMP RA-5(4) parameter requires the same monthly scanning frequency regardless of scope size. The finding is consistent across Vulnox LI-SaaS gap analysis engagements.
Control parameters do not scale down with scope. The 37-control LI-SaaS baseline contains parameter requirements that are as operationally demanding per control as Moderate. The total burden is lower because fewer controls apply. The per-control implementation standard is not.
LI-SaaS versus Moderate: what actually differs
FedRAMP LI-SaaS
37 controls from NIST 800-53. Self-attestation rather than 3PAO independent assessment. Requires sponsoring agency to accept risk without independent verification. Eligibility is binary: either the product stores no federal data on CSP infrastructure, or it does not qualify. No JAB authorization path -- LI-SaaS operates exclusively through the Agency ATO pathway. ConMon obligations still apply, including monthly scan submissions and annual penetration tests. SSP updates required for any change that affects the data storage or transmission scope.
LI-SaaS is faster and cheaper to authorize when the product genuinely qualifies. The risk is that eligibility is determined partly by the sponsoring agency's ISSO, not just by the CSP. An ISSO who interprets data storage broadly can reject a LI-SaaS package that the CSP believed was clearly compliant. Budget for the possibility of a Moderate path as a fallback.
FedRAMP Moderate
325 controls from NIST 800-53 with FedRAMP-specific parameter overrides. Independent 3PAO assessment required. Both Agency ATO and JAB P-ATO pathways available. Covers systems processing CUI. 12 to 18 month timeline to initial ATO. Higher cost assessment and ongoing ConMon. Authorization is more portable across agencies than LI-SaaS because the 3PAO provides independent assurance that reduces agency-level review burden.
Moderate is the right path for any SaaS product that stores, processes, or transmits federal data -- including audit logs with user identifiers. It is also the right path for CSPs who cannot accept the eligibility risk of LI-SaaS agency review. A Moderate authorization is harder to obtain and harder to maintain, but it is also harder to invalidate after the fact.
Self-attestation is a risk transfer, not a burden reduction
Common belief
Most CSPs frame LI-SaaS self-attestation as a compliance simplification. No 3PAO engagement, no independent testing, lower cost. The assumption is that self-attestation describes a lighter compliance obligation.
What we found
In Vulnox gap analysis engagements for LI-SaaS candidates, the most common outcome after a thorough control assessment is a recommendation to pursue Moderate rather than risk self-attesting to a control baseline that cannot be fully verified without independent testing. The authorization cost difference is real. The self-attestation liability exposure is also real. Most compliance officers, when both are on the table, choose the path with independent verification.
Self-attestation under LI-SaaS transfers risk acceptance from an independent assessor to the sponsoring agency's ISSO. The CSP is not attesting to a lower standard -- they are attesting to the same FedRAMP control requirements with no independent verification buffer. When a 3PAO issues a Security Assessment Report with findings, those findings are disclosed. The agency makes an informed risk decision. When a CSP self-attests, any undisclosed gap -- an SC-8 failure from a missed sidecar injection, a RA-5(4) parameter error, an audit log that should not exist -- is the CSP's unilateral representation to the federal government that controls are implemented correctly. A discovered inaccuracy in a self-attestation is not treated the same way as a post-assessment finding. It is treated as a misrepresentation. The regulatory exposure is different in kind, not just degree. For CSPs operating in regulated industries or with legal counsel familiar with federal contracting, this distinction matters before authorization is submitted, not after a gap is discovered.
LI-SaaS failure modes that appear after authorization
Product feature expansion that crosses the eligibility boundary
LI-SaaS eligibility is assessed at authorization time. It is not continuously re-evaluated by the PMO unless a CSP submits a significant change request. CSPs that expand their product post-authorization -- adding analytics, enabling API integrations that return agency data, introducing a new logging backend -- frequently cross the data storage threshold without triggering an SSP update. The authorization remains formally valid. The product is no longer eligible for LI-SaaS. If an agency ISSO discovers the discrepancy during annual review, the ATO is at risk of withdrawal.
Agency-to-agency ATO reuse expectations
FedRAMP authorizations are not transferable between agencies. Each agency must issue its own ATO. For Moderate authorizations with a 3PAO SAR, agencies often accept another agency's ATO with limited additional review because the independent assessment provides assurance. For LI-SaaS, agencies review the CSP's self-attestation package independently and apply their own ISSO's judgment. A package accepted by Agency A may be rejected by Agency B based on a different interpretation of the data storage criterion. CSPs that plan multi-agency expansion on the basis of one LI-SaaS acceptance should verify eligibility interpretation with each new agency before entering the authorization process.
ConMon understaffing post-authorization
LI-SaaS reduces the control count. It does not reduce the ConMon staffing requirement. Monthly vulnerability scan submissions, annual penetration tests, and POA&M management are required at LI-SaaS. CSPs that authorize under LI-SaaS and assume that the smaller control set translates to a lighter operational burden routinely understaff ConMon. The PMO's enforcement standard for ConMon submission failures does not distinguish between LI-SaaS and Moderate. Two missed monthly submissions is a documented revocation trigger at both levels.
Two structural problems building toward the surface
By Q3 2026, a documented LI-SaaS ATO revocation caused by post-authorization product expansion -- not security failure -- will prompt PMO guidance requiring annual LI-SaaS eligibility re-attestation as a ConMon deliverable.
LI-SaaS authorization has no mechanism for detecting product changes that cross the eligibility boundary post-authorization. The PMO currently relies on CSPs to submit significant change requests when product scope changes. Product teams do not consistently recognize eligibility boundary crossings as significant changes. The compliance drift rate of 35% within six months is consistent with this gap. A visible revocation will force the policy response.
Confidence: mediumPMO guidance issued before Q4 2026 introducing a LI-SaaS eligibility attestation requirement as part of annual ConMon review, or absence of such guidance.A mid-size collaboration SaaS company holding a LI-SaaS ATO will face a False Claims Act inquiry before 2027, triggered by a federal contracting officer's discovery that the product was storing federal user session metadata in a logging database that was not disclosed in the self-attestation package.
Self-attestation to federal security requirements carries FCA exposure that 3PAO-backed authorizations substantially reduce. LI-SaaS self-attestation packages are reviewed by agency ISSOs, not independent auditors. The gap between what CSPs disclose and what their systems actually do is documented in Vulnox assessment data at 35% drift. The legal theory connecting undisclosed federal data storage to FCA liability has been established in adjacent federal contracting cases. The combination of self-attestation, federal contracts, and documented compliance drift is structurally sufficient for exposure.
Confidence: mediumA publicly reported FCA inquiry or settlement involving a LI-SaaS CSP before January 2027 where the theory of liability involves self-attestation inaccuracy.
LI-SaaS is the right path for fewer products than the market assumes
The federal compliance market has absorbed LI-SaaS as an 'easy FedRAMP' narrative. Vendors position it as accessible, faster, and more affordable -- all of which are true in isolation. What the narrative omits is that LI-SaaS is a precise instrument for a narrow category of SaaS products, and the eligibility boundary is interpreted by agency ISSOs, not by the CSP. A CSP that pursues LI-SaaS without first confirming eligibility interpretation with the target agency's ISSO is making a regulatory bet on an outcome they do not control. My position is that LI-SaaS should be pursued only after a documented eligibility review with the sponsoring agency's ISSO, and only when the CSP has independent confirmation -- not internal assessment -- that the data storage criterion is satisfied. The time savings from skipping that step are real. The downside of a rejection nine months in is larger.
Counterargument
The counterargument is that requiring pre-authorization ISSO engagement adds timeline and relationship complexity to a process that is already slow. For CSPs with established agency relationships, this is manageable. For CSPs entering the federal market for the first time, it adds a barrier that LI-SaaS was designed to reduce. That is a reasonable concern. It does not change the risk calculus for CSPs who cannot afford a nine-month restart.
Before you choose LI-SaaS, answer two questions
Map every location where your application stores or transmits data generated by federal users. Include audit logs, session metadata, error logs, analytics event streams, and API response caches. If any of those locations reside on CSP-managed infrastructure, document the data type and retention period. Then ask the sponsoring agency's ISSO whether that storage pattern satisfies their interpretation of the LI-SaaS data storage criterion. Get the answer in writing before you scope your authorization effort. If the ISSO says yes, you have a defensible LI-SaaS eligibility determination. If the ISSO says no, you have saved nine months and $180,000.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisFedRAMP baselines explained: R4, R5, Low, Moderate, High, and LI-SaaS
FedRAMP LI-SaaS vs Moderate authorisation pathsNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideNational Vulnerability Database NIST
NIST National Vulnerability DatabaseOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
How many controls does FedRAMP LI-SaaS require compared to Moderate?
FedRAMP LI-SaaS requires 37 security controls from NIST 800-53. FedRAMP Moderate requires approximately 325. The 37-control LI-SaaS baseline reflects the assumption that the CSP has no independent federal data exposure -- the controls address residual risk only. If a product actually stores federal data, the LI-SaaS control set is miscalibrated for the actual risk.
What disqualifies a SaaS product from FedRAMP LI-SaaS eligibility?
Any persistent storage of federal data on CSP-managed infrastructure disqualifies a product from LI-SaaS. This includes audit logs containing federal user identifiers, session metadata, error logs capturing request payloads, and analytics databases. The criterion is not limited to structured PII or CUI -- it covers any data generated in the context of federal user interaction that the CSP retains. Agency ISSOs interpret this broadly.
Is FedRAMP LI-SaaS self-attestation really faster than getting a 3PAO assessment?
LI-SaaS's technical authorization timeline is 6 to 9 months, versus 12 to 18 months for Moderate. The gap narrows when agency review cycles are included. Agencies review LI-SaaS self-attestation packages more independently and often more slowly than Moderate 3PAO packages, because there is no independent assessment to rely on. A rejection at agency review forces a restart on a Moderate path with no credit for prior work.
What happens to a LI-SaaS authorization if the product adds new features post-authorization?
Product changes that introduce new data storage, new integrations that return federal data, or new logging capabilities can cross the LI-SaaS eligibility boundary without the authorization being automatically invalidated. The CSP is responsible for submitting a significant change request when product scope changes affect the SSP. Vulnox research shows 35% of authorized LI-SaaS environments drift out of compliance within six months, often through undisclosed product expansion.
What regulatory risk does self-attestation create that a 3PAO assessment does not?
Self-attestation is a direct representation to the federal government that controls are implemented correctly. A gap discovered after self-attestation is treated as a potential misrepresentation, not a standard compliance finding. For CSPs operating under federal contracts, undisclosed control failures in a self-attested package carry False Claims Act exposure that 3PAO-backed authorizations substantially reduce. The legal exposure is different in kind from a post-assessment finding.
Can a LI-SaaS authorization be reused across multiple federal agencies?
No FedRAMP authorization is transferable between agencies -- each agency must issue its own ATO. For LI-SaaS specifically, each agency's ISSO reviews the self-attestation package independently and applies their own eligibility interpretation. A package accepted by one agency can be rejected by another based on a different interpretation of the data storage criterion. CSPs planning multi-agency expansion should verify eligibility interpretation with each target agency before entering the authorization process.
Does FedRAMP LI-SaaS still require continuous monitoring after authorization?
Yes. LI-SaaS ConMon obligations include monthly vulnerability scan submissions, annual penetration tests, and POA&M management. The PMO's enforcement standard does not distinguish between LI-SaaS and Moderate. Missing two consecutive monthly scan submissions is a documented ATO revocation trigger at both levels. The smaller control set does not reduce ConMon staffing requirements.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.