IRS Publication 1075: Software Evidence for State Agency Vendors

IRS Publication 1075 (Rev. 11-2021, still the current revision on irs.gov) requires any agency that receives federal tax information (FTI) to run NIST SP 800-53 Rev. 5 controls on every system that touches it, including software a vendor builds. For vendors, that means a supported, inventoried, regularly scanned and promptly patched product, with evidence for each release.

The agency is the one that answers to the IRS. It passes those duties to you through the acquisition contract, the Exhibit 7 safeguarding language when you handle FTI, and the questions its reviewers ask during an on-site or remote safeguard review. This post covers what the publication actually says about flaw remediation, vulnerability scanning, unsupported components and the supply chain, what the IRS test matrices check in an application, and how to produce the evidence from your own build pipeline without tax data ever reaching your tooling.

A naming note before we start, because the two names are close. The IRS Office of Safeguards is the IRS office that enforces Publication 1075. Safeguard (safeguard.sh) is the software supply chain security company that publishes this blog. They are unrelated, and nothing here suggests the IRS has reviewed, approved or endorsed Safeguard.

Key takeaways

• Current revision, confirmed on irs.gov. The Office of Safeguards page links Publication 1075 Rev. 11-2021, which aligned Section 4.0 to NIST SP 800-53 Rev. 5.
• The statute is 26 U.S.C. 6103(p)(4). It makes safeguards, and an annual report to the IRS, a condition of receiving FTI.
• Contractors are in scope for review. Section 3.2 puts technology owned or managed by the agency's contractors and sub-contractors, application development contractors included, inside the assessment scope.
• Patch windows come from an IRS technical assistance page, not the publication text. Patches for FTI system components must start within 30 days of availability and finish within 90. Critical and high patches must be on all systems within 30 days.
• Scanning is every 30 days, application level included. RA-5 sets the 30-day cadence, and its supplemental guidance says monthly scans must include application-level data.
• Unsupported components draw critical findings. SA-22 says to replace them, and extended support that ships no security patches does not count.
• The application test matrix now asks for an SBOM. SCSEM test APP-72 has reviewers examine one. Publication 1075 itself never uses the word.
• There is no Publication 1075 certification for a product, a vendor or a tool. Compliance is judged agency by agency, in safeguard reviews.
• Safeguard capabilities covered, with maturity labels: SBOM generation and analysis (GA); software composition analysis and vulnerability management with EPSS and KEV (GA); reachability analysis (GA); policies and gates (GA); compliance and GRC suite, including the NIST SP 800-53 and Dependency Age framework pages (GA); bulk export (GA); CLI and local runner (GA); on-prem and air-gapped deployment and Zero AI mode (GA); autonomous remediation (GA, ships switched off with every category set to Manual); SAST and DAST (GA, not relied on here); fork and patch (GA); desktop app.
• FTI never enters this flow. You scan source, build output and release images on your side. No tax data, no production database, no test fixture built from live FTI.

Scope and a caution

This post reads Publication 1075 Rev. 11-2021, the Office of Safeguards technical assistance pages, the Generic Application SCSEM, and NIST and CISA sources. It is not legal advice. The agency decides how it meets Publication 1075, the Office of Safeguards decides whether it has, and your contract decides what you owe. Many states add their own security standards, so read those too.

Who must follow Publication 1075, and how it reaches contractors

The statute and the agency

The legal root is 26 U.S.C. 6103(p)(4). It lists the agencies and other recipients that may receive returns or return information, and it makes six things a condition of receiving it. They must keep standardized records of requests and disclosures, store the information in a secure area, restrict access to people whose duties require it, apply any other safeguards the Secretary prescribes, file a report describing their procedures, and return or destroy the information when they are done with it. Publication 1075 is how the IRS spells out those conditions in practice.

The recipients that matter here are state revenue, child support and benefits agencies, though federal agencies and some local bodies are bound too.

The Office of Safeguards and the review cycle

The Office of Safeguards describes its own role as verifying compliance with the 6103(p)(4) requirements by finding and reducing the risk of loss, breach or misuse of FTI held by outside government agencies. It does that in two ways.

The first is the Safeguard Security Report. An agency needs an approved SSR before it gets FTI, should submit it at least 90 days ahead, and must update it every year by its state's due date, certified by the head of the agency. In it, the agency explains, control by control, how it protects FTI.

The second is the safeguard review. Section 1.6 describes reviews that can be on-site, remote or a hybrid of both. Section 3.2 explains the IT side. Cybersecurity reviewers assess the agency's FTI inventory, which must include every system and supporting component that receives, accesses, stores, processes, protects or transmits FTI. They do it with Safeguards Computer Security Evaluation Matrices (SCSEMs), automated compliance tools run with IRS audit profiles, and manual testing through interviews, documents and onscreen configuration checks.

Where the vendor comes in

Section 3.2 is the sentence a vendor should read first. The assessment scope covers technology owned and managed by the agency, a state's consolidated IT organisation, the agency's constituent counties, and the agency's contractors and sub-contractors. Its examples include print vendors, collection agencies and application development contractors.

How tightly the rules bind you depends on whether you touch FTI.

• If you host, operate, support or develop against FTI, you are a contractor receiving it. Section 1.9.4 requires the agency to notify the Office of Safeguards before re-disclosing FTI to a contractor, and to get written approval before FTI goes on to a sub-contractor. Section 2.E.6.2 sets that notice at 45 days before the planned re-disclosure and names cloud providers, consolidated data centres and IT support among the examples. Section 2.C.10 says every contractor that receives, transmits, processes or stores FTI on the agency's behalf is subject to review and testing.
• If you only ship software that the agency runs, you never receive FTI, and Section 1.9.2 notes that only contracts for services needing FTI access must comply with these standards. Your product is still a component inside the agency's FTI system. Every control in Section 4.0 applies to it once it is installed. The agency enforces those controls through the acquisition contract, which SA-4 requires to include security requirements, documentation requirements and clear allocation of responsibility for security and supply chain risk management.

Either way, the agency needs the same evidence about your software.

Exhibit 7, the contract language

Exhibit 7 is the safeguarding language the agency must put into contracts. Section 2.C.10 says the agency must include it in all contracts, and Section 1.9.2 tells the agency to check that any contract authorising FTI disclosure has it.

Several clauses land directly on a vendor's engineering practice:

• Clause I(7) says every computer system that receives, processes, stores or transmits FTI must meet Publication 1075, with managerial, operational and technical controls available and turned on.
• Clause I(8) bars subcontracting any work involving FTI without the IRS's prior written approval, and I(9) requires the safeguard terms to flow into any approved subcontract without modification.
• Part III gives the IRS and the agency the right, with 24 hours' notice, to inspect the contractor's facilities. That includes manual or automated scanning tools for compliance and vulnerability assessments of IT assets that touch FTI.

One drafting detail: the 2021 highlights and Section 2.F.4 refer to Exhibits 7a (general services) and 7b (technology services), but the Rev. 11-2021 PDF prints a single Exhibit 7. Ask the agency which text your contract uses.

Which controls cover flaw remediation, scanning and unsupported components

Section 4.0 is the control catalogue. It follows NIST SP 800-53 Rev. 5 control names, with IRS-defined parameters filled in. Four controls carry most of the weight for a software vendor. For background on each underlying NIST control, see our posts on SI-2 flaw remediation and RA-5 vulnerability scanning.

SI-2, flaw remediation

The base control has four parts. Identify, report and correct system flaws. Test software and firmware updates for effectiveness and side effects before installing them. Install security-relevant updates promptly after release. Make flaw remediation part of configuration management.

The enhancements are where it gets specific:

• CE-2 requires automated checks, at least monthly, that system components have applicable security updates installed.
• CE-3 requires measuring the time between flaw identification and flaw remediation, with agency-defined benchmarks based on criticality.
• CE-4 and CE-5 call for automated patch management tools and automatic installation of security updates on all FTI systems.
• CE-6 requires removing previous versions of software components after updated versions are installed.

CE-3 matters most to a vendor. If you cannot say when you learned of a flaw and when you shipped the fix, the agency cannot measure its time to remediate either.

The patch windows

The publication says "promptly" and leaves the benchmarks to the agency. The Office of Safeguards fills that gap on its technical assistance page on configuration and patch management planning. Its mandatory requirements for FTI systems are blunt:

• Security patches for components that store, transmit, process or receive FTI, explicitly including applications, must be applied starting no later than 30 days after availability and completed by 90 days.
• Security patches must not be tested on systems with FTI.
• All system components on FTI systems must be under current vendor support.

The page also gives a sample schedule and says FTI system patches must be treated as no lower than Medium priority.

Two consequences follow. The agency's 30-day window for a critical patch includes the time you take to ship a fixed build, so a vendor who needs three weeks leaves the agency one week to test and deploy. And because patches must not be tested on FTI systems, the agency tests your update without real data, so your release notes have to carry the weight.

RA-5, vulnerability monitoring and scanning

RA-5 in Publication 1075 sets a concrete cadence. Scan the system and hosted applications every 30 days, before a new system goes on the agency network, to confirm that remediation worked, and whenever new vulnerabilities that may affect the system are reported. Use tools that follow standards for naming platforms and flaws and for measuring impact. Analyse the results. Fix legitimate vulnerabilities based on the agency's risk assessment. Share what you learn so the same flaw is fixed elsewhere.

The supplemental guidance says monthly scans must cover inventory, configuration and vulnerability data, "including at the application-level". CE-2 requires the vulnerability data itself to be refreshed at least every 30 days and before each scan.

SA-22, unsupported system components

SA-22 gives two options. Replace a component when its developer, vendor or manufacturer no longer supports it. Or provide an extended security support agreement that delivers security patches and firmware updates from an outside source for each unsupported component.

The supplemental guidance warns that systems which no longer receive security patches or product updates may receive critical findings during Safeguards reviews. The patch management page goes further. It says extended support programs that give access only to old patches, with no new security fixes, do not meet the support requirement.

For a vendor, "component" means the runtime, framework, application server and each library you ship, not just your product's major version. The Generic Application SCSEM says so explicitly.

The IRS page on FTI in open source software ties this back to open source. It reminds agencies that SA-22 requires all components to be supported, and it sets two conditions for open source that handles FTI. Software that transmits FTI must encrypt it with a FIPS 140 module validated through NIST's Cryptographic Module Validation Program. The software must be supported by a vendor or an organised community. A library whose maintainers have walked away fails the second test, however stable it looks. Our post on end of sale, end of support and end of life explains how those dates differ.

Supply chain and developer controls

Publication 1075 carries the NIST supply chain family into the FTI context:

• SR-2 requires a supply chain risk management plan for systems that process, store or transmit FTI, reviewed every three years.
• SR-3 requires a process to find and address weaknesses in the supply chain elements of FTI systems, documented in the security plans. Its CE-3 requires the same controls to flow down from prime contractor contracts to subcontractor contracts. See our SR-3 explainer for the NIST background.
• SR-6 requires assessing supply chain risks from suppliers and contractors at least annually.
• SR-10 requires inspecting hardware and software components that touch FTI, upon delivery, to detect tampering.
• SR-11 requires anti-counterfeit policy and procedures.

The developer controls in the System and Services Acquisition family put more directly on you:

• SA-11 requires the developer to plan and run security assessments, produce evidence of the testing and its results, implement "a verifiable flaw remediation process", and correct the flaws found. Its enhancements call for static code analysis (CE-1), manual code review of FTI-related applications (CE-4) and penetration testing at a minimum whitebox level (CE-5).
• SA-15 requires a documented development process that names its standards and tools and is reviewed at least annually.

Publication 1075 sets the controls but not the method. For the method, NIST SP 800-161 Rev. 1 is NIST's guide to cybersecurity supply chain risk management, and NIST SP 800-218, the Secure Software Development Framework, describes the developer side. Its practice PS.3 covers keeping provenance data, such as an SBOM, for every component of each release, and RV.1 and RV.2 cover finding, assessing and fixing vulnerabilities after release.

CM-8, component inventory

CM-8 asks the agency for an inventory that accurately reflects the system, includes every component, avoids double counting, and records the details needed for accountability. Publication 1075 lists software licence information, software version numbers and component owners among those details, and requires a review at least annually. CE-1 requires updating the inventory whenever components are installed, removed or updated. CE-3 requires automated detection of unauthorised hardware, software and firmware.

What the SCSEMs test that touches your software

SCSEMs are the spreadsheets reviewers fill in during a safeguard review, published so agencies can prepare. There is one per platform, from operating systems and databases to containers and a Generic Application matrix. Each row has a test ID, the NIST control, the method, expected results, a criticality rating and an issue code.

The Generic Application SCSEM is version 4.1. Its dashboard gives a release date of 26 January 2026, and the IRS download page lists an effective date of 13 March 2026. Several of its tests are, in practice, tests of the vendor's work.

APP-72 deserves a closer look. Its change log shows it was added in version 4.0, dated 31 March 2025. The test procedure asks the reviewer to "examine SBOM and other artifacts", and the matching issue code reads, in short, that no SBOM is produced for the system or application. Publication 1075 never mentions an SBOM. The test matrix now does.

Two more details matter. APP-01 says even a custom application maintained by agency staff must have every component and framework supported. And WEBAPP-5 notes that infrastructure or network scans alone do not count as web application scanning.

How to document component inventory and suppliers for a safeguard review

The agency has to show a reviewer an inventory that matches CM-8, an SBOM for APP-72, and supply chain controls under SR-3. It can only do that for your product if you hand it the data. A useful package for each release has five parts.

1. An SBOM per release, in SPDX or CycloneDX. Generate it from the build that actually ships, not from a manifest in a branch. CISA's 2026 Minimum Elements for an SBOM, published 29 July 2026 with international partners, updates the 2021 NTIA list. It adds or changes elements such as SBOM author, author signature, generation context, tool name, component producer, component hash and component licence. Use it as your checklist for what each SBOM should carry. For how states are starting to ask for SBOMs in procurement, see our post on state and local government SBOM mandates.
2. A supplier and support record per component. For each component, record who produces it and whether it is supported, with the end-of-support date where the producer publishes one. This is what APP-01 and SA-22 test.
3. A vulnerability report tied to the SBOM. Known vulnerabilities at release time, fixed versions, and your decision on each, including why any finding is not exploitable in your product.
4. Release and fix dates. When you learned of each fixed flaw and when the fix shipped. This feeds the agency's SI-2 CE-3 measurement.
5. A short statement of development practice. Your testing, review and gating steps, matching SA-11 and SA-15.

How to prove unsupported components are gone, or covered

SA-22 leaves two outcomes: the component is replaced, or it is covered by an extended support agreement that still delivers security patches. Proving either takes three pieces of evidence.

First, a per-release list of components with their support status. Version age is an early warning, not proof: an old release of a maintained library may be supported, while a recent release of an abandoned one is not.

Second, for anything unsupported you cannot remove yet, a dated plan naming the component, the replacement, the target release and the interim mitigation. The agency's plan of action and milestones (POA&M) entry for your product will depend on it.

Third, if you rely on extended support, the contract showing security patches are included.

Removal has to be complete. SI-2 CE-6 asks for old versions to be removed after updates, and APP-69 asks for unused libraries to be removed from releases. A vendored copy of an old library will still show up in a scan.

How to keep scanning on your side so FTI never leaves the agency

The cleanest way to stay out of FTI handling rules is never to have FTI in your tooling. The IRS page on live data testing says live FTI in test environments should generally be avoided and is not approved unless the Office of Safeguards specifically authorises it, with dummy data used wherever possible.

For software supply chain evidence, you do not need FTI, ever. What you scan is code and build output:

• Scan source, build output and the release images or installers in your own CI, before delivery.
• Keep test fixtures synthetic. If a fixture was built from a production extract, treat it as FTI and remove it from repositories and images.
• Do not point scanning tools at agency databases, file shares, logs or backups. None of those are needed to produce an SBOM of your product.

If the agency wants its own scans inside its boundary, it can scan the release artifacts it receives from you, which also covers RA-5's scan before a new system joins its network.

How Safeguard does this job

Safeguard's part is the software supply chain: what is in each release, which known vulnerabilities affect it, whether components are old or abandoned, whether a release met your policy, and the export that carries that evidence to the agency. It runs on your code and build artifacts and never receives FTI.

Step by step

1. Decide what gets scanned. List your repositories, the build that produces each release, and the release images or packages delivered to each agency. Exclude anything that holds or could hold FTI: production data, extracts, logs and backups.

2. Install the CLI and sign in on a build machine. The CLI and its local runner are GA. Safeguard's docs give the install as:

   curl -fsSL https://cli.safeguard.sh/install | bash
   

   Then run safeguard to open the interactive terminal and type /login. Your browser opens, you approve the session, and the runner starts. According to the runner docs, it polls the platform over outbound HTTPS that it opens itself, nothing connects to it, it runs each scan locally, and it uploads only the resulting SBOM and findings, never your source code.

3. Generate the SBOM and findings for each release. SBOM generation and analysis is GA, in SPDX and CycloneDX. From the command line the docs show:

   # A local directory (your own or proprietary code)
   safeguard scan --dir .
   # A private registry
   safeguard scan --image myregistry.azurecr.io/myapp:v1 \
     --registry-username "$REGISTRY_USER" \
     --registry-password "$REGISTRY_PASSWORD"
   # An SBOM you already have (SPDX or CycloneDX, detected automatically)
   safeguard scan --sbom sbom.json
   

   Results land as JSON under ./output, including vuln.json, license.json and collection.json. To see a scan in the platform with your other projects, run /scan . from the interactive terminal while signed in. The docs note that safeguard scan does not fail on findings; gating is done by policy gates in the platform.

4. Validate SBOMs before they go to the agency. If you build SBOMs with another tool, or receive them from a sub-contractor, check them against the format specifications. The docs show safeguard validate sbom.json --strict -o report.json, which checks CycloneDX, SPDX and VEX documents and treats warnings as errors under --strict.

5. Keep scanning between releases. Software composition analysis and vulnerability management are GA. Safeguard's docs say it rescans every project daily as new vulnerabilities are disclosed, and you can add triggers on push, on a schedule, or on release when a new tag is created. That gives you a dated record for RA-5's 30-day cadence and for its "when new vulnerabilities are identified" trigger. Use safeguard update on a build machine to refresh the local vulnerability databases before a scan, which matches RA-5 CE-2.

6. Triage with exploit data, then reachability. In the Vulnerabilities tab, findings sit under Critical, High, Medium, Low and Exploitable. Each one shows the CVE, CVSS score, EPSS score, whether it is actively exploited (from the CISA KEV catalog), the affected component, the fixed version and reachability. Reachability analysis is GA, including static reachability for Ruby, PHP and Swift or Objective-C. Filters such as kev:true and reachable:true give you a working queue. Use it to order work inside the IRS windows: a reachable, KEV-listed critical goes first, but an unreachable high still has a 30-day deadline.

7. Record decisions you will be asked about. Mark False Positive takes a justification and can require approval. Accept Risk takes an expiration date and a business justification and goes for approval. Both leave the record you need when an agency asks why a CVE is still in a build.

8. Turn your rules into policies and a release gate. Policies, gates and guardrails are GA. In Settings, then Policies, Create Policy lets you set conditions such as vulnerability severity, CVSS or EPSS thresholds, licence, component age (the docs' example is "No components older than 2 years") and maintenance (no abandoned packages), each with an action of Block, Warn or Notify. With policy outcomes on for your workspace, the docs show a CI step that fails when a gate fails:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   A blocking gate on critical findings is the mechanical version of APP-47's go or no-go expectation. Exceptions need a request, an approver and an expiration date, with an audit trail. Our post on proving every production release passed a security gate covers the gate record in more depth.

9. Use the Dependency Age framework for aging and end-of-life work. The compliance and GRC suite is GA, and Dependency Age is one of its internal frameworks, on by default unless you switch it off in Compliance, then Manage. Its scan-decided requirement, AGE-1 Dependency Freshness, checks each component's release date against what the scan found. Components are flagged as stale at two years and very old at four. Its control catalog adds controls for abandoned project detection (AGE-03), end-of-life tracking (AGE-04), major version lag (AGE-05) and release cadence (AGE-06). Only AGE-1 is decided by a scan. The other controls, end-of-life tracking among them, are evidenced the way the docs describe: automated tests, uploaded evidence, policies or an attestation. That is the right split for SA-22. Age is a signal Safeguard computes, while support status is a fact you confirm with the producer.

10. Map findings to NIST SP 800-53 on the framework page. The NIST SP 800-53 framework page is part of the same suite. Its scan-decided requirements cover CM-8 (inventory, and inventory accuracy with name and version), SI-7 (hashes for delivered components), SR-4 (provenance, including who created the inventory), SR-3 (the supplier of each component known and recorded), RA-5 (standard identifiers such as PURL or CPE so components match vulnerability databases) and SI-2 (known versions so patches can be determined). There is no Publication 1075 framework page, and SA-22 is not among this page's scan requirements, so treat it as the NIST layer of your evidence. Publication 1075 parameters, like the 30-day scan cadence and patch windows, you map yourself.

11. Fix, then rescan to confirm. Autonomous remediation is GA, and it ships switched off, with every category set to Manual until you enable it. With it on, the AI Remediate button on the Vulnerabilities page generates remediation plans and fix pull requests, and View Fix shows upgrade options with breaking change warnings, so your engineers review changes before merge. After the fixed release builds, rescan it. RA-5 lists confirming remediation as a reason to scan, and WEBAPP-6 expects a rescan showing the fix worked.

12. Export the release evidence. Bulk export is GA, in formats including CSV, Excel, PDF, JSON and XML. Export the SBOM, the vulnerability list with decisions, the gate result and the Dependency Age results for each release, and deliver them with the build. That package is what the agency attaches to its own records. It is not an SSR, and you should not label it as one.

13. Run the platform where the agency is comfortable. On-prem and air-gapped deployment are GA. Safeguard's air-gapped docs describe signed snapshot bundles carrying vulnerability feeds, CISA KEV and daily EPSS into the perimeter, with nothing inside calling out. Zero AI mode, also GA, runs the platform with no language model in the loop.

Requirement, what Safeguard does, what you still own

What the agency still owns

Your evidence feeds the agency's compliance; it does not replace it. The agency writes and certifies the SSR, keeps the FTI inventory, files the 45-day notices before any contractor gets FTI, puts Exhibit 7 and SA-4 terms in contracts, hosts the safeguard review, answers the SCSEMs, runs its own infrastructure scans, and tracks findings in its corrective action plan. It also decides who can access FTI, and nothing in this flow changes that.

What Safeguard does not do

Honest limits, so nobody plans a safeguard review around a gap:

• It never receives FTI in this flow, and the IRS does not review it. Safeguard is not IRS approved, and there is no such thing as a Publication 1075 certification for a tool, product or vendor. Using Safeguard does not make your product compliant. It produces evidence that the agency can use in its own compliance work.
• It has no Publication 1075 framework page. The NIST SP 800-53 and Dependency Age pages cover the component evidence. The IRS-specific parameters, the SCSEM mapping and the SSR text are yours to map.
• It covers software components, not the agency's whole control set. Operating system and database hardening under the platform SCSEMs, the IRS audit-profile compliance scans, encryption with validated FIPS 140 modules, multi-factor authentication, audit logging of FTI access, physical security, background investigations and training are outside what this flow does.
• It does not know every producer's end-of-support date. Dependency Age measures release age and policies can flag abandoned packages. Whether a component is still supported under SA-22 is a fact you confirm and record.
• Its SAST and DAST engines are generally available. Do not plan to meet SA-11 CE-1 static analysis, CE-5 penetration testing or the WEBAPP-5 web application scan solely with them. Manual code review under CE-4 is always a human task.
• It does not install patches on agency systems. It helps you ship a fixed release faster. The agency still tests and deploys it within its windows.
• It does not write contracts or reports. Exhibit 7 terms, notices, the SSR and corrective action plans stay with the agency and you.
• Its own certifications are limited. Safeguard's SOC 2 Type II audit is in progress. Its architecture is designed for FedRAMP High, a design target rather than an authorisation.

Common mistakes

Assuming Publication 1075 does not apply because you never see FTI. Your product becomes a component of an FTI system the day it is installed, and Section 4.0 applies to it there.

Letting tax data into the toolchain. A test database seeded from a production extract or a log bundle on a support ticket puts FTI where no safeguard plan covers it. Supply chain scanning needs none of it.

Producing an SBOM once, at contract award. APP-72 and CM-8 CE-1 assume the inventory tracks what actually ships.

Relying on infrastructure scans for application vulnerabilities. The SCSEM says plainly that network scans are not sufficient for web application scanning, and RA-5 asks for application-level data each month.

Counting extended support without security patches. The patch management page says that does not meet the requirement. Check what your support contract actually delivers.

Using KEV as the deadline instead of the order. KEV status says what to fix first, but Publication 1075 never mentions it, and an unlisted high-severity flaw still has a 30-day deadline. CISA's BOD 26-04, which replaced BOD 22-01 in June 2026, binds federal civilian agencies only; treat it as a model, not a state requirement.

Confusing the names. In proposals and questionnaires, keep "Office of Safeguards" (the IRS) and "Safeguard" (the tool) clearly apart. Never write that a product is "Safeguards approved" or "Publication 1075 certified".

Forgetting your own suppliers. SR-3 CE-3 expects controls to flow down to subcontractors, so their components need the same SBOM and patch evidence.

FAQ

What is the current version of IRS Publication 1075?

The current revision is Rev. 11-2021, titled Tax Information Security Guidelines for Federal, State and Local Agencies, as linked from the IRS Office of Safeguards program page in October 2026. It superseded the November 2016 edition, took effect six months after publication, and aligned Section 4.0 to NIST SP 800-53 Rev. 5.

Does IRS Publication 1075 apply to software vendors that never see FTI?

Not directly as a contractor, because only contracts for services needing FTI access must comply with the contractor standards. But your software becomes part of the agency's FTI system, every Section 4.0 control applies to it there, and the agency passes those duties to you through the acquisition contract under SA-4.

Is there an IRS Publication 1075 certification for software?

No. The IRS Office of Safeguards assesses agencies through the SSR and safeguard reviews, which can extend to contractors. No product, vendor or tool is certified as Publication 1075 compliant.

How fast must security patches be applied on systems with federal tax information?

The Office of Safeguards patch management page requires FTI system patches to start within 30 days of availability and finish within 90 days. Its sample schedule puts critical and high patches on all systems within 30 days, with critical distribution starting within 72 hours.

How often does Publication 1075 require vulnerability scanning?

RA-5 requires scans every 30 days, before a new system joins the agency network, to confirm remediation, and when new vulnerabilities that may affect the system are reported. Monthly scans must include application-level data, and the vulnerability data must be updated at least every 30 days.

Does IRS Publication 1075 require an SBOM?

The publication itself does not mention SBOMs. The Generic Application SCSEM does. Test APP-72, added in version 4.0, has reviewers examine an SBOM and check that its vulnerabilities are being remediated, under control SR-10.

What is an SCSEM?

A Safeguards Computer Security Evaluation Matrix is the spreadsheet IRS reviewers use to test a platform during a safeguard review. The Office of Safeguards publishes one per platform, including a Generic Application matrix, so agencies can prepare their environments beforehand.

Can open source software be used in systems that process FTI?

Yes, with conditions. The IRS page on open source requires a FIPS 140 validated encryption module for software that transmits FTI, and support from a vendor or an organised community.

Can a contractor run vulnerability scanning for the agency?

Yes. An Office of Safeguards technical assistance answer says an agency may use a contractor for risk assessment work such as vulnerability scanning. The agency remains responsible for the policy.

Getting the evidence ready before the next review

Start with the release in the field today. Generate its SBOM, list its known vulnerabilities with decisions, check each component's support status, and date anything you fixed in the last 90 days. That package answers most of what an agency asks under CM-8, RA-5, SI-2, SA-22 and APP-72. Then automate it for every release.

If you want to try the flow on your own code, install the CLI from safeguard.sh/download and read the Safeguard documentation. For related reading in this series, see CJIS Security Policy evidence for public safety software vendors, keeping a contract promise of no known exploited vulnerabilities and stopping vulnerable dependencies at five checkpoints.

The IRS windows count from the day a fix is available, so the time you spend waiting for an upstream release comes out of the agency's 30 or 90 days. The section below covers how Safeguard helps when a fix exists but has not reached your build, and when upstream has no fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner. You set it up on your own machine, approve it with its device code, then scan from the terminal. A vendor serving a tax or benefits agency would run the same pattern on a build server, so each release gets an SBOM and findings while source code stays on the machine and no agency data is ever involved.

Click through it at your own pace, or open it full screen.

The second demo is a session in the Safeguard desktop app. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. For a Publication 1075 customer, that reviewed, tested change is the start of the SI-2 trail: a dated fix your team approved before it went into a release.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IRS: Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies, Rev. 11-2021 (PDF)
• IRS: Safeguards program
• IRS: Safeguard Security Report (SSR)
• IRS: Configuration and patch management planning
• IRS: Use of federal tax information in open source software
• IRS: Use of live FTI in system testing
• IRS: Safeguards technical assistance, policy and procedures involving a contractor
• IRS: Safeguard Computer Security Evaluation Matrix (SCSEM)
• IRS: SCSEM updates
• IRS: Safeguards SCSEM, Generic Application, version 4.1 (XLSX)
• Legal Information Institute: 26 U.S. Code 6103, Confidentiality and disclosure of returns and return information
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST: SP 800-218, Secure Software Development Framework Version 1.1
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA and partners: 2026 Minimum Elements for a Software Bill of Materials (PDF)
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard Docs: Dependency Age framework
• Safeguard Docs: NIST SP 800-53 framework
• Safeguard Docs: Generate SBOM
• Safeguard Docs: Vulnerabilities
• Safeguard Docs: Policies and Gates
• Safeguard Docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard Docs: Local Runner
• Safeguard Docs: CLI Usage
• Safeguard Docs: Air-Gapped Deployment

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.