FIPS Certificate Standing

3 of your 7 systems rely on cryptographic modules that lose federal procurement standing on 21 September 2026 - 7 days from now.

Of those, 4 require confirmation before being cited in correspondence - see the status column.

Read for this report: 15 software components across 7 systems. No operating system was named in the inventory, so nothing here assesses the OS cryptographic modules.

What this means

Historical status governs NEW federal procurement: agencies should not include historical modules in new acquisitions. It does NOT stop deployed systems from operating. Continued use is permitted, but NIST makes it conditional: agencies may make a risk determination on whether to continue, based on their own assessment of where and how each module is used.

In sixty seconds, if this was forwarded to you

FIPS 140 is the US standard for validating cryptographic modules - the library or device that actually performs the encryption. It has had three revisions: 140-1, long withdrawn; 140-2; and 140-3, the current one. A module is tested once, against one revision, and receives a certificate naming the exact versions tested.

Certificate standing is whether that certificate is still current. On 21 September 2026 every remaining FIPS 140-2 certificate moves to NIST's Historical list. Standing governs new federal procurement - agencies are directed not to include historical modules in new acquisitions. It does not switch running systems off, and continued use is permitted on an assessment of where and how each module is used. It bites at a contract action or an assessment, not on the date.

CMVP is the Cryptographic Module Validation Program - the NIST program that runs those tests and publishes the list of what has passed. Every certificate in this report is a row on that public list; where you see "CMVP" below, it means "the official NIST list of approved encryption".

This is not the post-quantum transition, and the two are commonly confused in both directions. FIPS 140-3 is a revision of the validation standard; ML-KEM and ML-DSA are new algorithms on a separate and later timetable. They meet at one point, and it is the one worth knowing: a module must hold a current FIPS validation before it can carry a validated post-quantum implementation. An estate that has not resolved this arrives at the post-quantum requirement still carrying it.

What this assessment could see

The checks below did not pass. They do not make the findings wrong; they bound what the findings describe.

Limitation (PLAUS-02). The typical machine here lists only 2 component(s). A real operating system carries far more.

This usually means the export was filtered - a single product, a search term, or one console page. Re-export without the filter. An assessment of a filtered inventory describes the filter.

Limitation (SCOPE-04). No firewalls, routers or hardware security modules were supplied.

A large share of the certificates retiring on 21 September belong to hardware, and no package manager lists a firewall. Send a device list with host, vendor, model and firmware - it is usually the smallest file in the building.

Limitation (COV-01). No directory census was supplied, so coverage cannot be measured.

Send a list of the computer accounts in your directory. Without one, this report can describe the machines in the files you sent but cannot say how many machines you have.

Limitation (LAYER-01). No operating-system row was read, so no host's OS build is known.

Include the operating-system row: our collector writes it, and an EDR or MDM device export carries it as OS name plus build.

Limitation (LAYER-03). No bundled cryptography was read. Four false all-clears in this product's history were bundled copies, so this absence is not evidence there are none.

Run the collector's file scan, or send a Defender export-assessment file, which carries diskPaths and needs no scan.

Limitation (LAYER-05). No EDR, VPN or backup product was found in the inventory. Every estate runs some; their absence here means the inventory does not list them, not that they are absent.

Include the security products in the software export. They are cryptographic products and their modules need certificates too.

What this report does not decide

This report covers everything in the inventory you supplied, and treats every item the same way. It does not decide which of these items are in scope for CUI (Controlled Unclassified Information - sensitive government information that is not classified), and nothing in it says that an item is in scope or out of it.

For a contract that carries a CMMC Level 2 requirement (CMMC is the Defense Department's cybersecurity program for contractors), scope is set by the categories in 32 CFR 170.19, Table 3. Three of them, in the rule's own words:

CUI Assets: "Assets that process, store, or transmit CUI"

Security Protection Assets: "Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope"

Out-of-Scope Assets: "Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUI Assets"

OSA is the rule's term for the organization being assessed. Deciding which of your items falls into which category is your organization's decision, documented in its asset inventory and System Security Plan (the document describing how an organization protects CUI), not in this report.

How to read the tables below

Some of these words look like the tool gave up. None of them means that, and the difference between them decides what to do next - so it is worth thirty seconds before the findings.

The Certificate column

The Standing column

The Status column

How much weight the row carries, kept deliberately separate from the finding itself.

And the one thing none of these says

No value in these tables is a determination of compliance. Certificate standing is read from the CMVP record; whether your implementation satisfies a control is your assessor's decision and your affirmation. We are not a testing laboratory, we do not certify cryptographic modules, and we are not a C3PAO.

Findings

6 rows below show no FIPS validation standing for the version found in the NIST certificate record as of 14 Sep 2026 (marked None). NIST SP 800-171 3.13.11 reads: "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." Whether a row's encryption protects CUI is not something this report decides; see What this report does not decide above.

The 3 exposures to address first

1. bcryptprimitives.dll 10.0.20348.2402 on system-06

• Module: Cryptographic Primitives Library
• Certificate: #4825 (FIPS 140-2)
• Evidence: rule CLIFF-002, matched by exact_version
• 140-3 path: #5410
• Vendor status: Microsoft Corporation holds active FIPS 140-3 certificate(s) 5313, 5404, 5405, 5406. This is the vendor's, not necessarily this product's - ask which release carries it.
• CMVP queue: no submission found for this module. Microsoft Corporation has 1 other submission(s) in process: Kernel Mode Cryptographic Primitives Library (Finalization).
• The CMVP queue shows no submission for this module. Ask the vendor, in writing, whether a submission exists and keep the reply - that written answer is the evidence.
• Other certificates also name this module: 5410 (FIPS 140-3, active) names 10.0.20348.30000
• More than one certificate can cover a product; confirm which one this product actually ships before relying on any single number.

2. cng.sys 10.0.20348.2402 on system-06

• Module: Kernel Mode Cryptographic Primitives Library
• Certificate: #4766 (FIPS 140-2)
• Evidence: rule CLIFF-002, matched by exact_version
• 140-3 path: #5408
• Vendor status: Microsoft Corporation holds active FIPS 140-3 certificate(s) 5313, 5404, 5405, 5406. This is the vendor's, not necessarily this product's - ask which release carries it.
• CMVP queue: Kernel Mode Cryptographic Primitives Library - FIPS 140-3, Finalization since 2026-08-17. A further submission, build not stated. FIPS 140-3 certificate #5408 for this module has already issued and names other builds of this release; this queue entry names no build and is not that certificate. It is not a validation and confers no standing on its own.
• Other certificates also name this module: 5408 (FIPS 140-3, active) names 10.0.20348.30000
• More than one certificate can cover a product; confirm which one this product actually ships before relying on any single number.

3. gnutls 3.6.16-8.el8_10 on system-01

• Module: Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module
• Certificate: #4272 (FIPS 140-2)
• Evidence: rule CLIFF-011, matched by exact_version
• 140-3 path: not researched
• Vendor status: Red Hat®, Inc. holds active FIPS 140-3 certificate(s) 4804, 4846, 4857, 5022. This is the vendor's, not necessarily this product's - ask which release carries it.
• CMVP queue: no submission found for Red Hat®, Inc. on the public list as at the assessment date. Absence is not proof of inaction - the list is a point-in-time capture. Ask them in writing.
• Other certificates also name this module: 3813 (FIPS 140-2, historical), 3956 (FIPS 140-2, historical), 4272 (FIPS 140-2, active), 4428 (FIPS 140-2, active)
• More than one certificate can cover a product; confirm which one this product actually ships before relying on any single number.

What else was read

Every component in the files supplied is accounted for here, so that nothing in this report is silent about a machine you sent.

15 components were read across 7 systems. 12 appear in the findings table above. 1 holds a validation that this date does not touch, and is listed below. 2 are components we recognize that carry no cryptographic module claim of their own.

Assessed, and not on the cliff

Each of these was matched to a certificate that keeps its standing past 21 September 2026. This is a statement about each component's certificate, not a clean bill of health for the estate - the coverage limits above still apply, and a machine can hold a current certificate for one library while running something else this assessment never saw.

What your vendors are doing about it

Every affected vendor is in one of three states. This comes from the public record - NIST's validated-module list and its Modules In Process list - not from vendor statements.

A vendor holding a FIPS 140-3 certificate does not mean the product you run is covered by it. Validation attaches to a specific module and version. Treat the third row as "there is somewhere to go", not as "you are fine".

What to tell your contracting officer

Pre-written language. Adjust the specifics, keep the scope - it is deliberately narrow and defensible.

As part of our preparation for the FIPS 140-3 transition, we have identified 6 component(s) in our environment whose cryptographic modules are validated under FIPS 140-2. In line with the CMVP transition, those validations move to the Historical list on 21 September 2026. Existing deployments continue to operate and remain supported for use in current systems; the change affects the modules' standing for new procurement. We are confirming FIPS 140-3 validation status with the relevant vendors and will provide a migration schedule. We would welcome confirmation of how this should be reflected in forthcoming contract actions.

Do not claim systems become insecure or stop working on 22 September. They do not, and saying so will cost you credibility with anyone who knows the program.

What this report could not see

This assessment was produced from a software inventory, which reaches the cryptography that packaged software declares. It does not reach hardware security modules, self-encrypting drives, TPMs and boot-path modules, network device firmware, or smart-card applets - all of which hold certificates on the same cliff.

Those are not beyond reach. Each needs one fact that no package manager records, and a short companion document lists exactly which ones apply to this estate, why each is being asked, and how to answer it in a couple of minutes.

Anything left unanswered stays in this report as a declared gap. It does not quietly become a clean result.

Questions you can answer

These are not limits of the assessment. Each is a component whose standing could not be confirmed because one fact is missing - and it is a fact you already have. Answering any of them resolves that component immediately.

gnutls 3.6.16-8.el8_10 on system-01

certificate(s) #4780, #4846 were excluded: they validate a different platform release than this package's '8' build.

Candidate certificates: 3813 (FIPS 140-2, historical), 3956 (FIPS 140-2, historical), 4272 (FIPS 140-2, active)

libgcrypt 1.8.5-8.el8_10 on system-01

certificate(s) #1305, #1757, #4754 were excluded: they validate a different platform release than this package's '8' build.

Candidate certificates: 3784 (FIPS 140-2, historical), 4397 (FIPS 140-2, active), 4438 (FIPS 140-2, active)

nss 3.90.0-7.el8_10 on system-01

certificate(s) #3860, #4498, #4774 were excluded: they validate a different platform release than this package's '8' build.

Candidate certificates: 3839 (FIPS 140-2, historical), 3946 (FIPS 140-2, historical), 4413 (FIPS 140-2, active)

gnutls 3.6.16-8.el8_10 on system-02

certificate(s) #4780, #4846 were excluded: they validate a different platform release than this package's '8' build.

Candidate certificates: 3813 (FIPS 140-2, historical), 3956 (FIPS 140-2, historical), 4272 (FIPS 140-2, active)

Your calendar

The dates this estate runs out of, in order. Every one is the sunset date on a certificate something here rests on, taken from the certificate itself rather than from a rule of thumb.

The next one is 21 September 2026, 7 days from this assessment - 5 certificates, 3 systems.

21 September is the largest date here and it is not the last one. A FIPS 140-3 certificate is not permanent cover - it sunsets on its own schedule, and one date above falls after the one everyone is currently looking at. A report that was correct in September is quietly wrong by the next row in this table, and nothing announces it.

If you assess again with a later edition of the tool, the comparison names what changed and whether it changed because your estate did or the record did.

Answers for your prime

One row per product and version found, laid out to be copied into a prime contractor's security questionnaire (a prime is the larger contractor that hired you). Each cell is dated and states what NIST's certificate list showed, or what a vendor wrote to you. No cell is a statement that a requirement is met - that is your assessment and your affirmation.

This table lists every product in the inventory you supplied. It does not say which of them are in scope for CUI, and it names no machine; the last column counts how many carry each row.

Where you can shrink scope

This report lists every item you supplied. For a contract that carries a CMMC Level 2 requirement, the scoping rule, 32 CFR 170.19 Table 3, describes Out-of-Scope Assets in four sentences. In the rule's own words, in the order it gives them:

"Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUI Assets"

"Assets that are physically or logically separated from CUI assets"

"Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset"

"An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset"

A VDI client is software that shows a desktop running on another computer; Keyboard/Video/Mouse means only keystrokes, the picture of the screen and mouse movements pass between the two.

For an item you treat as out of scope, the same table's requirement is:

"Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI"

Choosing where your boundary sits is your organization's decision, documented in its asset inventory and System Security Plan. This report does not recommend a boundary, a product or a design.

Appendix - draft Plan of Action entries

This is a draft for you to edit, not a filed plan. It exists because a finding with no route is worth less than a finding with one, and because the route already exists in the regulation.

32 CFR 170.4 describes a temporary deficiency as one where "remediation of a discovered deficiency is feasible, and a known fix is available or is in process". Whether a gap meets that is for your assessment. The CMVP queue line under each exposure records whether the public list shows a submission for the module, and the Evidence column below repeats it, as one fact an assessment may weigh.

Three things are deliberately blank, because they are yours: the owner, the target date, and the compensating control. We do not know your program and a document that guessed would be worth less than one that asks.

What the class means

A certificate is not a patch. Nothing is installed when one issues, and the machine does not change - which is why the class matters more than the finding. Certificate #4825 was validated on 7 October 2024 and names Windows builds that shipped in 2020 and 2021: machines already in production became covered without being touched.

The question to put to every vendor on an A or a P row is the same one, and almost nobody asks it: does the certificate - or the pending submission - name the exact version we are running? If it does, there is nothing to deploy at all.

The control this answers to

NIST SP 800-171 3.13.11 - "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." Reached through DFARS 252.204-7012 on any contract involving CUI, and assessed under CMMC as SC.L2-3.13.11.

In plain terms, for anyone who does not live in these acronyms: CUI is Controlled Unclassified Information - sensitive government data that is not classified but must still be protected. DFARS 252.204-7012 is the contract clause that puts that duty on defense contractors, NIST SP 800-171 is the checklist it points to, and CMMC is the program that checks a contractor meets it. If none of your contracts involve CUI, this control does not apply to you.

The distinction the control turns on, and the one an assessor will press: FIPS-approved algorithms are not FIPS-validated cryptography. The module implementing the algorithm has to carry its own certificate. Enabling FIPS mode configures which algorithms are used; it does not create a validation.

What this appendix does not do

• It does not make you compliant, and nothing in it should be read as saying you are. Compliance is your assessor's determination.
• It does not decide that a deficiency is temporary. You make that case and your assessor accepts or rejects it; this supplies the evidence the case needs.
• It gives no completion dates. NIST publishes no expected duration for any CMVP review phase and directs enquirers to the vendor for schedule. Any date in this plan must come from your vendor, in writing.

Appendix - the assessment view

The report above is organized by system, which is how the work gets done. An assessor reads control, then evidence, then gap, then plan - so the same findings are set out that way here.

SP 800-171 3.13.11 - CMMC practice SC.L2-3.13.11

Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

This is the one control this assessment speaks to directly. It reaches it because the control turns on whether a cryptographic module holds a current FIPS validation, and that is a fact in the public CMVP record rather than a judgment about your systems.

Controls this report must NOT be cited for

Several controls mention cryptography. This assessment does not evidence them, and citing it for one of them is worse than citing nothing: an assessor who finds a report used for a control it cannot reach stops trusting it for the control it can.

What this report is. Evidence about certificate standing, produced independently and dated. It is not a determination of compliance with 3.13.11 or anything else - that determination is the assessor's, on the whole implementation, of which this is one input.

Methodology and limits

What this rests on

Every finding above names the certificate it rests on, and every certificate is a public NIST record you can look up yourself. The inputs are listed below with their versions and dates so the same assessment can be reproduced and checked.

The assessment performs no scanning, needs no deployment, and reads nothing from your network.

Progress between reports. To show progress since an earlier report, keep that report's JSON export (the json command) and run the next report with it (--previous). The progress line then counts gaps and documented gaps in both, and appears under the headline.

Reproducibility

Re-running with the same inputs reproduces this document exactly. Nothing here depends on the wall clock.

Check the digest yourself. sha256sum on the inventory you sent should print the value above. If it does not, this report was produced from a different file and should not be relied on.

What this does not cover

• Whether a validated module was actually in use. An inventory shows what is installed, not what was loaded and enabled. OpenSSL 3.x, for example, ships its FIPS provider as a separate component that must be explicitly activated.
• Cryptography outside packaged software - hardware modules, HSMs, firmware, embedded devices and anything statically linked.
• Whether the module was used in an approved mode of operation.
• Any judgment about the security of your systems. This report is about procurement standing, not about risk.

About the vendor status column

Vendor status is read from two NIST sources on the assessment date: the validated-module list and the Modules In Process list. Three things follow from that, and all three matter:

• It is a point-in-time reading. A vendor shown with no public path may submit next week.
• Absence of a public record is not proof of inaction. A vendor may be mid-validation without appearing, or may be validating under a company name not yet linked to the one you know. Corporate mergers make this genuinely hard: one well-known vendor's replacement certificate is filed under the legal name of a company the customer has never heard of.
• Posture belongs to the vendor, not to your component. A vendor holding a 140-3 certificate has not necessarily validated the product you run.

This is why the column tells you what to ask rather than what to conclude.

Source

• NIST CMVP FIPS 140-3 Transition Effort - all FIPS 140-2 validation certificates move to the Historical list on 2026-09-21, regardless of security level or original issue date

Certificate numbers cited above should be verified directly against the CMVP validated-modules search before being used in contractual correspondence.

Before you rely on this report

This report describes the inventory you supplied. It cannot describe what the inventory left out.

We do not hold a copy of your asset register, and we do not want one - that is why the self-run route exists and why we ask for no host names. The consequence is unavoidable and worth stating plainly: a system missing from your inventory is missing from these findings, and its absence leaves no trace. No assessment can detect what it was never shown.

Reconciling this report against your complete estate is your step, and only you can take it. Five things to do before this document is used in a contract action or an assessment:

1. Check the count. Compare the systems listed here against your asset register or CMDB. If your register says 340 servers and this report covers 290, find the 50 before you rely on either number. 2. Cover what an inventory cannot reach. Hardware modules, HSMs, network device firmware, self-encrypting drives, TPMs, boot-path modules and smart-card applets hold certificates on the same schedule and appear in no package list. The companion document lists the ones that apply to you. 3. Confirm each finding with the vendor. Every certificate here is public and numbered. Ask the vendor directly what they intend to do about the module you run - the answer is theirs to give, not ours. 4. Have your assessor or contracting officer confirm applicability. Whether a finding affects a particular obligation is their determination. This report is evidence for that conversation, not a substitute for it. 5. Re-run when things change. A new system, an upgrade, a vendor re-validation or an ageing snapshot each change the answer.

No assessment tool offers complete detection, in this field or any other in security. What we commit to is narrower and checkable: every finding is traceable to a numbered public record, every limit is declared in writing, and nothing is presented as certain when it is not. Where we cannot reach a conclusion, this report says so rather than reporting a clean result.

---

License and confidentiality

Licensed to Sample estate (illustrative, not a real customer) (reference SAMPLE). This report and the software that produced it are supplied under license for assessing systems your own organization owns or operates. Not for redistribution, resale, or use in building a competing or substantially similar product or service. The license terms and any non-disclosure agreement in force between the parties govern.

Produced by AGILICRYPT(TM) FIPS CertStanding(TM). Copyright (c) 2026 AGILICRYPT LLC. All rights reserved. AGILICRYPT and FIPS CertStanding are trademarks of AGILICRYPT LLC. Product and company names are the trademarks or registered trademarks of their respective owners, used here only to identify the products a certificate covers. Their use implies no affiliation with, or endorsement by, those owners.

Next steps

Before you sign. Under DoD (Department of Defense) policy as of 14 September 2026, your own signed assessment is the main evidence — and DoD can still check it. If you want someone who has read the record behind each finding to review your plan before you sign, see agilicrypt.com/advisory or write to advisory@agilicrypt.com. The current policy position is kept on that page.

What this report could not see

Your report was produced from a software inventory. Measured against everything that loses standing on 21 September, an inventory of that kind reaches about 71%.

The rest are not beyond reach. Each needs one fact that no package manager records: a model number, a firmware version, or an answer to a question only you can answer.

Below is what would close them, for your estate specifically. Nothing here is a form - each item says why it is being asked and how to answer it in a couple of minutes.

1. Is FIPS mode actually enabled on these systems, and how do you know?

This report says whether a certificate keeps its standing. It cannot say whether the validated module was switched on. An OpenSSL FIPS provider can be installed and never loaded, which looks identical in an inventory.

How to answer:

• Windows: reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy" /v Enabled
• Linux: cat /proc/sys/crypto/fips_enabled
• Linux: openssl list -providers
• Or the relevant line from your system hardening standard

Asked because: asked of every estate - it is the limit stated on every report.

2. Vendor, model and firmware for your network devices - firewalls, routers, switches, VPN concentrators, wireless controllers.

43 certificates in this class lose standing on 21 September.

No network devices appeared in what you sent. They are rarely in a software inventory and they carry their own certificates, which name exact models and firmware.

How to answer:

• One line per device: vendor, model, firmware version

Asked because: no network devices were present in the inventory.

3. Storage array models, and the part numbers of any self-encrypting drives.

31 certificates in this class lose standing on 21 September.

Self-encrypting drives and storage controllers hold their own validations. The drive model is what the certificate names, and it is not something an operating system inventory reports.

How to answer:

• The array's own console, or the procurement record
• Linux: lsblk -o NAME,MODEL,SERIAL

Asked because: asked of every estate - drive-level validation is invisible.

4. Do you operate any hardware security modules or key managers? Make, model and firmware version of each.

28 certificates in this class lose standing on 21 September.

HSMs are almost always FIPS-validated, frequently under 140-2, and they never appear in a software inventory. They are also the systems where a lost validation matters most, because they are usually there to satisfy a control in the first place.

How to answer:

• Thales Luna: lunacm -> 'hsm showinfo'
• Entrust nShield: 'enquiry' (look for the firmware line)
• Or the model and firmware from the support portal / asset record

Asked because: asked of every estate - an HSM is invisible to the first pass.

5. Server and laptop models, or the TPM manufacturer and firmware version.

15 certificates in this class lose standing on 21 September. No software inventory can find them - not ours, and not a competitor's.

Boot managers, code-integrity modules and TPM chips hold certificates on this cliff and appear in NO software inventory - ours or anyone else's. A TPM is a physical chip; it is found from the machine model or the purchase record. One major TPM manufacturer currently has no FIPS 140-3 certified part at all, so this class is worth checking rather than assuming.

How to answer:

• Windows: Get-CimInstance -Namespace root\CIMV2\Security\MicrosoftTpm -ClassName Win32_Tpm | Select ManufacturerIdTxt,ManufacturerVersion
• Or: Get-CimInstance Win32_ComputerSystem | Select Manufacturer,Model

Asked because: Windows systems were present.

6. Do you issue smart cards, PIV credentials or hardware authenticators? Product name and applet version.

1 certificates in this class lose standing on 21 September.

Card applets carry their own validations, separate from the reader and from the systems that use them.

How to answer:

• The issuance system's product record, or the card vendor

Asked because: asked of federal suppliers - PIV is common and never inventoried.

7. Which managed cloud or SaaS platforms hold data covered by your FIPS obligation, and what has each provider committed to in writing?

Where a platform manages the cryptography - a managed database, a serverless runtime, a SaaS application - the validation is the provider's, not yours. Nothing you can export will show it, and this report does not cover it. But the obligation still reaches you at your next contract action, and the only evidence that answers it is a statement from the provider.

How to answer:

• List the platforms first: which ones actually touch covered data
• For each, ask the provider in writing: which FIPS-validated modules underpin the service, and what is their transition plan
• FedRAMP services: the answer is usually in the package on the FedRAMP Marketplace, and your sponsor can obtain it
• Keep the reply. A provider's written statement is the evidence; your own inventory cannot substitute for it

Asked because: asked of every estate - inherited cryptography is invisible to any inventory, including a competitor's.

---

Why we are telling you this

Every assessment has a boundary. Most reports do not say where theirs is, which makes a clean result and an unanswerable question look identical on the page.

The list above is the boundary of the first pass, stated in full. Answer as much or as little as is useful - each answer closes a specific class of certificate, and anything left unanswered stays in the report as a declared gap rather than quietly becoming a clean result.