Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / What Is CMMC Compliance? A Complete Guide

What Is CMMC Compliance? A Complete Guide

If you work with the U.S. Department of Defense in any capacity, CMMC compliance is not optional. It is the price of admission. And if you are not prepared, it could cost you your contracts, your reputation, and your seat at the table in the defense industrial base.

This guide breaks down everything you need to know about CMMC compliance clearly, honestly, and without the jargon overload.

What is CMMC

What Is CMMC Compliance?

CMMC stands for Cybersecurity Maturity Model Certification. It is a framework developed by the U.S. Department of Defense (DoD) to ensure that defense contractors and subcontractors adequately protect sensitive government information from cyber threats.

In plain terms: if you handle federal data, especially sensitive technical or operational information, the DoD wants proof that your cybersecurity practices are up to standard. Not a promise. Actual, verified proof.

CMMC compliance means meeting a defined set of cybersecurity practices and, depending on your level, having those practices certified by an accredited third-party assessor, also known as a C3PAO (Certified Third-Party Assessment Organization). It is structured, tiered, and increasingly enforced, particularly since the final CMMC rule was formally codified into federal acquisition regulations in December 2024.

Why CMMC Compliance Matters for Defense Contractors

The defense sector is one of the most targeted industries for cyberattacks. According to IBM’s Cost of a Data Breach Report, the average cost of a data breach reached $4.45 million in 2023, and breaches involving government data carry consequences far beyond the financial hit.

Foreign adversaries, particularly nation-state actors, have been systematically targeting defense contractors to steal intellectual property, weapons designs, and operational intelligence. The DoD created CMMC specifically to close the gaps in the Defense Industrial Base (DIB) cybersecurity posture.

For defense contractors, CMMC compliance matters for three hard reasons:

  • Contract eligibility. CMMC requirements are embedded directly into DoD contract solicitations. If you do not meet the required CMMC level, you cannot bid. Full stop.
  • Legal and regulatory liability. Under the False Claims Act, misrepresenting your cybersecurity compliance when submitting to a federal contract can result in significant legal exposure, treble damages, and penalties.

Supply chain trust. Even if you are a subcontractor, your prime contractor is responsible for ensuring your compliance. Failure on your part puts their contracts at risk too.

The History and Evolution of CMMC

From CMMC 1.0 to CMMC 2.0: What Changed?

CMMC was first introduced in 2020 as CMMC 1.0, a five-level model that drew heavily from existing NIST frameworks. It was ambitious but widely criticized for being overly complex, expensive to implement, and difficult to scale, especially for small and medium-sized businesses in the defense supply chain.

In response to industry feedback, the DoD released CMMC 2.0 in November 2021, streamlining the model significantly. The five levels were reduced to three. The most notable change was the elimination of unique CMMC-specific practices, bringing the framework into direct alignment with NIST SP 800-171 and NIST SP 800-172.

CMMC 2.0 also introduced a critical flexibility provision: certain Level 2 contractors may be permitted to perform annual self-assessments rather than requiring a third-party audit, depending on the sensitivity of the information they handle.

The final CMMC rule was published in the Federal Register in December 2024, officially codifying CMMC 2.0 into the Defense Federal Acquisition Regulation Supplement (DFARS).

How CMMC Relates to NIST SP 800-171 and DFARS

NIST SP 800-171 is the foundational document underpinning CMMC Level 2. It outlines 110 security practices across 14 control families designed to protect Controlled Unclassified Information (CUI) in non-federal systems.

DFARS clause 252.204-7012 has long required defense contractors to comply with NIST SP 800-171 on a self-attestation basis. The core problem? Self-attestation created significant inconsistency and allowed non-compliant contractors to fly under the radar.

CMMC changes that by adding mandatory third-party verification for a large portion of the DIB, bringing real accountability into the equation for the first time.

The Three Levels of CMMC 2.0 Explained

CMMC 2.0 organizes compliance into three progressive levels. Each level corresponds to the type of information your organization handles and the sophistication of threats you may face.

CMMC Level 1: Foundational

Who it applies to: Contractors who handle Federal Contract Information (FCI) but not CUI. Requirements: 17 basic cybersecurity practices drawn from FAR clause 52.204-21. Assessment method: Annual self-assessment with an executive affirmation submitted to the Supplier Performance Risk System (SPRS). Level 1 is the baseline. Think good cyber hygiene, things like using antivirus software, controlling who has access to systems, and keeping your software updated. Not glamorous, but non-negotiable.

CMMC Level 2: Advanced

Who it applies to: Contractors who handle Controlled Unclassified Information (CUI). Requirements: All 110 practices from NIST SP 800-171, organized across 14 domains. Assessment method: Either triennial third-party assessment by a Certified Third-Party Assessment Organization (C3PAO) or annual self-assessment, depending on contract criticality. This is where the majority of the defense contractor community lands, and where most of the compliance effort (and cost) is concentrated. If your organization touches CUI in any meaningful way, Level 2 is almost certainly your target.

CMMC Level 3: Expert

Who it applies to: Contractors supporting the DoD’s most critical programs, handling CUI that presents higher-risk threat vectors, often involving advanced persistent threats (APTs). Requirements: 110+ practices from NIST SP 800-171 plus select practices from NIST SP 800-172. Assessment method: Government-led assessment conducted by the Defense Contract Management Agency (DCMA). Level 3 is the top tier. If you are here, you already know what you are dealing with, and so do your adversaries.

CMMC Level Information Type Practices Required Assessment Type
Level 1: Foundational FCI 17 (FAR 52.204-21) Annual self-assessment
Level 2: Advanced CUI 110 (NIST SP 800-171) C3PAO or self-assessment
Level 3: Expert CUI (high-value) 110+ (NIST SP 800-172) Government-led (DCMA)

Who Needs to Be CMMC Compliant?

Prime Contractors

Any organization that holds a DoD contract involving FCI or CUI must comply with the applicable CMMC level. Prime contractors are typically well-resourced enough to navigate the process, but that does not make them exempt from the hard work, or from the downstream obligations to their supply chain.

Subcontractors and the Defense Supply Chain

CMMC requirements flow down through the supply chain. Prime contractors are obligated to ensure that their subcontractors meet the required CMMC level for the work they perform. If a subcontractor touches CUI, they need Level 2 certification. No exceptions.

This creates a significant compliance burden across the Defense Industrial Base, which includes over 300,000 companies, the vast majority being small and medium-sized businesses.

Federal Contract Information (FCI) vs. Controlled Unclassified Information (CUI)

FCI is information provided by or generated for the government under a contract for the development or delivery of a product or service. Think of it as general contract-related information not intended for public release.

CUI is a broader and more sensitive category, technical data, engineering drawings, export-controlled information, and other sensitive but unclassified data designated by the government under the CUI Program. CUI triggers Level 2 requirements.

If you are unsure which category your data falls under, that ambiguity itself is a compliance risk.

Key CMMC Compliance Requirements

CMMC 2.0 at Level 2 maps directly to the 14 control families of NIST SP 800-171. Here are five of the most impactful domains, and where organizations most often fall short.

Access Control

This domain governs who can access your systems and data. It includes requiring multi-factor authentication (MFA), enforcing least privilege access, controlling remote access sessions, and managing mobile devices. Access Control contains 22 practices at Level 2, the largest domain in the framework, and often one of the most technically involved to fully implement.

Incident Response

You must have a documented, tested incident response plan. It needs to include detection, reporting, containment, and recovery procedures. Contractors must also report cyber incidents to the DoD within 72 hours under DFARS 252.204-7012. “Tested” is the operative word here, a plan that only exists on paper will not satisfy a C3PAO.

Risk Assessment

Organizations must regularly assess risk to their systems, identify vulnerabilities, and act on findings. This includes vulnerability scanning and remediation, an area where many small contractors have significant gaps. A risk assessment is not a one-time checkbox; it is an ongoing operational requirement.

System and Communications Protection

This domain addresses network segmentation, encryption of CUI in transit and at rest, and protections against unauthorized data exfiltration. If your CUI is sitting on an unencrypted laptop or flowing through an unprotected email server, this is where you will fail, and it is one of the first places a C3PAO will look.

Audit and Accountability

You need to generate, protect, and review audit logs. Your systems must record who did what, when, and from where. For C3PAO assessments, auditors will review your logging infrastructure closely.

How to Achieve CMMC Compliance: Step-by-Step

Step 1: Determine Your Required CMMC Level

Start by reviewing your contracts and solicitations. What type of information are you handling, FCI, CUI, or both? Your required level flows from that determination. When in doubt, engage your contracting officer for clarification. Getting the level wrong early cascades into misspent effort across every subsequent step.

Step 2: Define Your CUI Scope and System Boundaries

Identify every system, application, and network component that touches, stores, processes, or transmits CUI. This is your CUI environment or assessment scope. Reducing scope intelligently, through network segmentation, for example, can dramatically reduce compliance costs. Scope control is one of the highest-leverage activities in the entire compliance process.

Step 3: Conduct a Gap Analysis

Compare your current security practices against the requirements of your target CMMC level. A structured gap analysis produces a list of deficiencies and a roadmap for remediation, and is the foundation of your Plan of Action and Milestones (POA&M). Not sure where to start? Our gap analysis services are designed exactly for this stage.

Step 4: Develop and Implement Security Policies and Controls

Policies alone do not make you compliant. Controls need to be implemented, tested, and documented. This phase is where the real work happens, configuring systems, training staff, deploying security tools, and building operational procedures. Expect this to take weeks to months depending on your current posture.

Step 5: Create and Submit a System Security Plan (SSP)

The System Security Plan (SSP) is a formal document describing your system boundary, the security controls in place, how they are implemented, and the responsible personnel. It is a living document, not a one-time submission. A well-written SSP is one of the first things a C3PAO will request, and a weak one sets a poor tone for the entire assessment.

Step 6: Undergo a CMMC Assessment

For Level 2 contractors requiring third-party certification, you will engage a C3PAO authorized by the CMMC Accreditation Body (Cyber AB). The assessment includes document reviews, interviews, and technical testing. Results are submitted to the DoD.

For Level 1 and eligible Level 2 self-assessments, scores are submitted to the Supplier Performance Risk System (SPRS) along with an executive affirmation. Need a clearer picture of what the certification process looks like end-to-end? See our certification services.

Step 7: Maintain Ongoing Compliance

CMMC is not a one-time certification. It requires continuous monitoring, annual affirmations, and triennial reassessments for Level 2 third-party certifications. Your security posture must remain active, not just documented.

CMMC Implementation Timeline

The DoD has been phasing in CMMC requirements through a structured rollout. With the final CMMC rule published in December 2024, requirements are now being embedded into new DoD contracts on a phased basis.


Phase 1 (Nov 10, 2025 – Nov 9, 2026): Organizations must complete self-assessments for CMMC Level 1 and Level 2 on certain contracts. Phase 2 (starting Nov 10, 2026): Introduces requirements for third-party assessments of CMMC Level 2. Phase 3 (starting Nov 10, 2027): Enforces assessment requirements for CMMC Level 3. Full implementation (by Nov 10, 2028): CMMC standards are integrated into all relevant DoD solicitations and contracts. 

The general expectation across the industry is that CMMC requirements will appear in the majority of DoD contracts by 2026, though specific timelines vary by contract type and program. Contractors should not wait for a contract requirement to appear before beginning preparation, the assessment pipeline is already forming, and C3PAO capacity is finite. Organizations that start late will find themselves competing for limited assessor availability under deadline pressure.

Common Challenges in Achieving CMMC Compliance

Scoping and CUI Identification

Identifying exactly what constitutes CUI within your organization is harder than it sounds. Many contractors discover they have been handling CUI without formally recognizing it, which retroactively creates compliance exposure. The National Archives CUI Registry is the authoritative reference for understanding what qualifies.

Resource and Budget Constraints for Small Businesses

The DoD’s own estimates suggest that CMMC Level 2 compliance can cost small businesses between $50,000 and $250,000 or more, depending on organizational size and current security posture. For many small defense contractors, this is a significant financial burden, but the cost of non-compliance (lost contracts, legal exposure) is typically far higher. The DoD’s Project Spectrum platform offers free cybersecurity resources specifically targeted at small DIB companies.

Documentation and Evidence Collection

Technical controls are only part of the equation. C3PAOs need documented evidence that those controls exist and function consistently. Many organizations have solid security practices that are not documented, and undocumented controls do not exist in the eyes of an assessor. This is one of the most common failure points we see, even among organizations with strong underlying security.

Meeting All 110 NIST SP 800-171 Practices

Meeting all 110 practices requires sustained organizational effort, executive sponsorship, and often third-party expertise. There is no shortcut here, but there is a smarter path. Organizations that scope aggressively, automate where possible, and use compliance management tools move significantly faster than those trying to manage everything manually.

CMMC Compliance Costs: What to Expect

Compliance costs vary significantly based on organization size, existing security posture, and required CMMC level. Below is a general framework, use it for budgeting orientation, not as a fixed quote:

Cost Category

Estimated Range

Gap assessment

$2,000 – $15,000

Remediation (technology + implementation)

$10,000 – $100,000+

C3PAO third-party assessment (Level 2)

$10,000 – $100,000+

Ongoing compliance management (annual)

$10,000 – $50,000+

Managed Security Service Provider (MSSP)

Variable

 

The biggest cost variable is almost always remediation, and remediation cost is driven by how wide your current gap is. A thorough gap analysis early on is the single best investment you can make in controlling total compliance spend.

Tools and Resources to Help Achieve CMMC Compliance

Several authoritative resources support CMMC compliance efforts:

  • NIST SP 800-171 Self-Assessment Handbook and associated assessment guides are freely available through the NIST Computer Security Resource Center.
  • Cyber AB Marketplace lists all authorized C3PAOs and Registered Practitioner Organizations (RPOs), ensuring you work with legitimate, vetted assessment bodies.
  • DoD’s Project Spectrum platform provides free cybersecurity resources specifically for small businesses in the DIB.

On the technology side, organizations pursuing CMMC should evaluate tools across endpoint detection and response (EDR), SIEM, multi-factor authentication, and secure cloud environments, particularly those meeting FedRAMP or DoD IL2/IL4 requirements.

Compliance automation platforms can also significantly reduce manual overhead. If you are weighing your options, our comparison of compliance tools is a good starting point, or go deeper on Drata specifically, which is particularly well-suited to evidence collection workflows that CMMC assessors expect.

Ready to Get CMMC Compliant? Axipro Can Help.

CMMC compliance is complex, but it is entirely achievable, with the right expertise behind you. At Axipro, we work with defense contractors at every stage of the compliance journey: from initial scoping and gap analysis to SSP development, remediation support, and assessment readiness.

Whether you are a prime contractor preparing for a C3PAO audit or a subcontractor just trying to understand what level applies to you, we know exactly where the pitfalls are, and how to help you avoid them.

Explore our plans or contact Axipro to schedule a free CMMC readiness consultation. We will assess where you stand, what you need, and how to get there, without the fluff.

Frequently Asked Questions About CMMC

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

For the past two years, enterprise AI risk conversations have centered on a familiar set of concerns: model bias, hallucination, data privacy, and dependency on third-party models. These are real risks, and most organizations now run some version of a governance program to manage them. But something has shifted. Organizations are no longer just deploying AI that generates content for a human to review. They’re deploying AI that acts. Agents now plan multi-step tasks, call APIs, move data between systems, execute transactions, and coordinate with other agents, often with no human checkpoint in the loop. That shift deserves more than a footnote in the existing AI risk category. It deserves its own line in the risk register: Agentic Autonomy Risk. What Is Agentic AI Risk Management? Agentic AI risk management is the practice of identifying, assessing, and controlling the risks created when AI systems take autonomous action on an organization’s behalf. Where traditional AI governance evaluates outputs (accuracy, bias, privacy), agentic AI risk management governs what agents actually do: the tools they call, the permissions they inherit, and the downstream consequences of their actions. That distinction is the reason existing risk registers struggle with agents, and it’s worth unpacking properly. What Agentic AI Actually Changes Traditional AI systems, even generative ones, are advisory. They produce an output such as a summary, a prediction, a draft email, or a classification, and a human remains the last checkpoint before anything happens in the real world. Agentic AI removes that checkpoint. An agentic system doesn’t just produce an answer. It pursues a goal. It decides which tools to call and in what order, then executes those actions directly against live systems: submitting a purchase order, modifying a database record, sending an external communication, or orchestrating a set of sub-agents to complete a broader workflow. Agentic autonomy is the degree to which a system can plan and execute actions without a human explicitly authorizing each step. It’s a spectrum rather than a binary. At one end, the AI drafts and a human approves every action. At the other, the AI operates within broad guardrails and only escalates exceptions. The further an organization moves along that spectrum, the less its exposure looks like software risk and the more it looks like delegated authority risk, the kind normally reserved for employees, contractors, and automated financial systems. Why Existing Risk Registers Miss Agentic AI Risks Most enterprise risk registers were built on a reasonably safe assumption: a human initiates consequential actions, and the technology around that human behaves deterministically. Agentic AI breaks both halves of that assumption at once. A few specific gaps show up quickly when organizations try to map agentic deployments onto existing categories. Operational risk registers assume process failures come from human error or system outages, not from a system independently choosing an unanticipated path to a stated goal. Cybersecurity risk registers are built around unauthorized external access, while an agent problem usually involves an authorized system taking unauthorized internal actions with its own legitimate credentials. Model risk frameworks, borrowed largely from financial services, evaluate output accuracy rather than action consequences, which matters most when those actions can’t be reversed. And third-party risk assessments treat vendors as static entities, not as autonomous agents that might invoke other vendors’ agents on your behalf. See our guide to the NIST AI Risk Management Framework for how output-focused frameworks are structured. The result is a governance blind spot. An organization can be compliant against its AI policy, its cybersecurity policy, and its vendor risk policy, and still have nobody accountable for the specific risk of a system initiating a harmful sequence of actions before anyone notices. Defining Agentic Autonomy Risk Agentic Autonomy Risk is the risk that an AI system, operating with delegated decision-making and execution authority, takes actions that are harmful, non-compliant, or misaligned with organizational intent before adequate human oversight can intervene. Those actions might happen independently or in coordination with other agents. It deserves standing as a named category alongside cybersecurity, operational, legal, financial, and third-party risk because the loss event itself is different. The harm is a completed action in a live system, and it may be difficult or impossible to reverse. The accountability structure is different too: when an orchestrating agent delegates to sub-agents, responsibility for the outcome gets distributed in ways existing ownership models don’t cleanly capture. So is the detection window. Traditional controls assume a human is positioned to catch an error before it compounds, but an agent can execute dozens of dependent actions faster than any human review cycle. 7 Agentic AI Risk Scenarios to Put on Your Register 1. Unauthorized autonomous decision-making. An agent takes an action within its technical permissions but outside its intended business mandate. It adjusts pricing, approves a refund, or modifies a customer record, and no policy ever explicitly authorized that scenario. 2. Goal misalignment. The agent optimizes for a literal interpretation of its objective in a way that diverges from actual business intent, particularly under ambiguous or adversarial inputs. 3. Multi-agent interactions and cascading failures. One agent’s flawed output becomes another agent’s trusted input. A single error can propagate across a chain of agents faster than anyone can detect it, amplifying the original mistake instead of containing it. 4. Excessive tool or system permissions. Agents get provisioned with broad, standing access “to be safe” rather than scoped, least-privilege access tied to specific tasks. A productivity tool quietly becomes a privilege-escalation path. 5. Regulatory non-compliance. Autonomous actions trigger obligations under data protection, financial services, employment, or sector-specific regulation, and they execute without the compliance review a human-initiated process would normally receive. 6. Explainability and accountability gaps. An autonomous action causes harm and the organization can’t clearly reconstruct why the agent chose that path, or establish whether the business owner, the AI governance function, or the vendor is accountable for the outcome. 7. Autonomous third-party actions. A vendor’s agent, integrated into your environment, takes action on your behalf, or your agent acts against a

A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more. The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it. What Is SOC 2 Penetration Testing?​ A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper. That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes. How Penetration Testing Fits Into SOC 2 Compliance​ SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria. In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists. Is Penetration Testing Required for SOC 2?​ Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone. In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist. How Much Does SOC 2 Penetration Testing Cost? Typical Price Range for SOC 2 Pen Testing Most companies pay $1,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the lower end of the market start around $1,000 to $5,000. Deep manual testing from established firms runs $10,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting. Cost by Company Size (Startup, SMB, Enterprise) Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope. Cost by Test Type (Network, Web App, API, Cloud, Internal/External) Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $1,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly. Factors That Influence SOC 2 Penetration Testing Cost Scope and Number of Assets Tested Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor. Complexity of Application or Infrastructure​ A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access. Testing Methodology (Black Box, Grey Box, White Box) Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free. Depth of Testing and Manual vs. Automated Approaches Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope. Tester Credentials and Firm Reputation Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries

Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That