Software & Security Product Makers
Your code runs on your customers’ machines and inside their builds, signed with your keys and updated on your schedule — and if you make security, identity or cryptography products, it is part of their defences too. We test it the way an attacker would, and hand you evidence your next evaluator can review.
Book a ConsultationShipped to every customer, trusted by all of them
Software you ship runs on your customers’ trust: agents with administrator rights, clients holding tokens, SDKs inside other people’s products, and an updater that can replace all of it overnight. If you make security, identity or cryptography products, a flaw is a flaw in every customer’s defences — and a stolen signing key or hijacked update channel reaches all of them at once.
The rules have caught up. Under the EU Cyber Resilience Act, standalone software is a product: since 11 September 2026 manufacturers have had to report actively exploited vulnerabilities, including for products already on the market, and from 11 December 2027 its full requirements apply, with many security and platform products in its ‘important’ or ‘critical’ classes. Through national law, the revised Product Liability Directive treats software placed on the market after 8 December 2026 as a product too.
A CRA notified body may not take on work that conflicts with its independence — consultancy in particular — and EU certification rules hold evaluation labs to the same standard. Help before an assessment has to come from outside it: testing that finds the problems an assessor would look for while you can still fix them. That is our work, and our report is evidence they can review — never a substitute for their evaluation.
Three services, tuned to what you ship
Artificial Intelligence Security (AI-BOM)
Coding assistants that read repositories, triage models in security tools, and agents that can run commands, open pull requests or change policy. We test whether untrusted input — a code comment, a dependency’s README, a log line — can steer them, and what their credentials can do when it does.
Learn more →Post-Quantum Cryptography Readiness (CBOM)
An inventory of the cryptography you ship: the keys that sign your code, updates, licences and tokens, the TLS and certificates inside the product, and — for PKI, HSM and identity vendors — the algorithms customers will need. A root of trust shipped today has to stay trusted for the product’s life, and NSA’s CNSA 2.0 timetable for national security systems has software and firmware signing begin moving immediately, and use CNSA 2.0 only by 2030.
Learn more →Product Penetration Testing
Desktop clients and endpoint agents, installers and auto-updaters, SDKs and public APIs, licensing, and the build, signing and release pipeline. For security products we go further: tampering with or blinding the agent, abusing the console’s policy push, and extracting or misusing keys in PKI, HSM and identity products.
Learn more →Built for shipped software, not adapted from web testing
Rated on the trust boundary
We report what crosses a real boundary — local privilege, other users, other tenants, the server behind the client, the update channel — not the fact that a user can inspect software they own.
Attacked like a security product
We test your defence from the position of the attacker it is meant to stop: can malware with administrator rights tamper with or blind the agent, can a low-privileged console user push policy everywhere, can a caller extract a key it should only use?
The release path is in scope
Source control, build, signing and update get the scrutiny you give production: who can sign, what the updater accepts, whether a downgrade or a replayed update gets through, and whether you could prove a shipped binary came from the code you reviewed. We review the live pipeline read-only and prove attacks only in a test repository you provide.
Before the evaluation, not instead of it
We are not a notified body, an evaluation lab (ITSEF), a FIPS 140-3 laboratory, an NCSC-assured test facility or a WebTrust or ETSI auditor, and we never certify, attest or audit compliance. You may supply our report to them; it never stands in for their evaluation.
Where the rules stand for software and security products
Software is now a regulated product in the EU, and security products sit in its strictest classes. Each row gives its status and dates, current as of October 2026.
| Framework | Instrument | What it means for you |
|---|---|---|
| European Union | Cyber Resilience Act — Reg (EU) 2024/2847, scope Commission guidance — C(2026) 5252 (not yet adopted) | In force since 10 December 2024; most obligations apply from 11 December 2027. Standalone software is a ‘product with digital elements’, in scope when its intended or foreseeable use includes a data connection to a device or network; remote processing you design or are responsible for, without which the product cannot perform one of its functions, is part of the product. The Commission’s guidance (content approved 27 July 2026; non-binding, and applying only once adopted) puts software installed on the user’s own system in scope and a browser-only web app outside it. |
| European Union | Cyber Resilience Act — reporting (Art 14) | Binding since 11 September 2026, including for products already on the market: actively exploited vulnerabilities and severe incidents go to the coordinating CSIRT and ENISA at once — an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure being available for a vulnerability, or a month after the notification for an incident. |
| European Union | CRA important products, Class I — Annex III Implementing Reg (EU) 2025/2392 (in force since 21 December 2025) | Software categories include identity and privileged-access management, browsers, password managers, anti-malware, VPNs, network management, SIEM, boot managers, PKI and certificate-issuance software, and operating systems. From 11 December 2027 they go to a notified body unless a harmonised standard, common specification or EU certification scheme at ‘substantial’ or above has been applied in full. Classification follows core functionality: embedding a browser does not make your product one. |
| European Union | CRA important products, Class II, and critical products — Annexes III and IV Implementing Reg (EU) 2025/2392 | Class II covers hypervisors and container runtimes, firewalls — web application firewalls and anti-spam gateways included — and network- and host-based intrusion detection and prevention. From 11 December 2027 they cannot self-assess, open source aside (see below): a notified body, or an EU certification scheme at ‘substantial’ or above once one is recognised under the CRA. The implementing regulation names hardware security modules as an example of a critical product (hardware devices with security boxes), alongside smartcards and secure elements; no act yet requires EU certification for them, so the same routes apply. |
| European Union | CRA and open source — Arts 13, 24 and recitals 15, 18 | The recitals, which guide interpretation, say open source you do not monetise is not a commercial activity, and list charging for the product, or for support beyond cost recovery, among the signs that it is. From 11 December 2027, open-source stewards — legal persons other than manufacturers that systematically support open source intended for commercial activities — have a lighter regime: a documented cybersecurity policy, cooperation with market surveillance authorities, reporting to the extent they are involved in development, and no administrative fines. From the same date, when you integrate third-party components, open source included, the duty of due diligence sits with you. Open-source products in Class I or II, unlike critical products, may still be self-assessed, provided their technical documentation is made public when they are placed on the market (Art 32(5)). |
| European Union | CRA notified bodies and standards — Chapter IV; request M/606 | The notified-body rules have applied since 11 June 2026; member states are to strive for enough notified bodies by 11 December 2026, and on 18 October 2026 the EU’s NANDO database listed none under the CRA. None of the 41 standards requested in February 2025 has yet been cited in the Official Journal. |
| European Union | EUCC — Implementing Reg (EU) 2024/482, as amended | The EU’s Common Criteria scheme, applying since 27 February 2025 and voluntary unless law says otherwise: an accredited lab (ITSEF) evaluates, a separate certification body certifies, and self-assessment is not permitted. A delegated act giving EUCC certificates a presumption of CRA conformity is planned for the first quarter of 2027; no draft has been published. |
| Publicly trusted CAs | CA/Browser Forum NCSSR v2.0.5 Mozilla Root Store Policy v3.1 | Version 2.0.5, effective since 3 July 2025, binds CAs through the Baseline Requirements and root programmes such as Mozilla’s (policy v3.1, effective 1 July 2026). Ballot NS-010, which would issue a restructured v2.0.6, is in its voting period. A CA must run penetration tests at least annually and after changes the CA defines as significant, by testers with the requisite skills, tools, proficiency, code of ethics and independence — covering certificate systems and, since 15 April 2026, security support systems and network boundary controls. |
| United States | FIPS 140-3 — cryptographic module validation | Effective since 22 September 2019 for US federal agencies; the CMVP views non-validated cryptography as providing no protection. Every FIPS 140-2 certificate is now on the Historical list, for existing systems only — and a module that binds to one follows it there. Modules are tested by independent NVLAP-accredited laboratories and validated by the CMVP (NIST with the Canadian Centre for Cyber Security). |
| US federal | Executive Order 14412 and OMB M-26-15 (June 2026) OMB M-26-05 (January 2026) | Binding on agencies. High-value assets and high-impact systems move to post-quantum key establishment by the end of 2030 and signatures by the end of 2031; M-26-15 implements this and excludes national security systems. A proposed rule holding covered contractors to the NIST FIPS, post-quantum included, by the end of 2030 is due around December 2026, not yet published. M-26-05 rescinded the secure-software attestation mandate, leaving no government-wide duty to submit CISA’s attestation form or an SBOM, though an agency may still ask for either by contract. |
| Guidance and voluntary | NIST SSDF — SP 800-218 v1.1 CISA Secure by Design pledge (US) Software Security Code of Practice (UK) | NIST’s SSDF remains at final v1.1 (February 2022), v1.2 a draft since December 2025, and gives penetration testing as a testing example. CISA’s pledge, for enterprise software makers (its sign-up template asks signers to confirm they serve US customers), and the UK Code (updated January 2026) are voluntary, with progress self-reported or self-assessed. CISA does not verify adherence and neither do we: we supply test evidence for your own report. |
What you get
- Findings rated on the trust boundary — pinned to the build, version and platform tested, with the boundary crossed and whether the fix ships as an update, a server-side change or a new signing key
- Signing and update-path assessment — who can sign, what your updater accepts, downgrade and replay protection, and how keys are stored and could be rotated
- Evidence for your next evaluation — results mapped to the CRA’s essential requirements and, where relevant, your Common Criteria or EUCC security target, FIPS 140-3 module or CA/Browser Forum testing programme, for your notified body, lab or auditor to review
- Critical findings in writing, on the day — timestamped, through a channel agreed at scoping
- Upstream register — flaws in third-party and open-source components, written up for their maintainers, with coordinated disclosure agreed before the report ships
- Cryptographic and AI bills of materials — in CycloneDX format
- Retest of fixes — evidence that remediation landed in a shipped build
Find the flaw before it ships in a signed update.
A software and security product engagement starts with what you ship, how it updates, and the evaluations and markets ahead of you.
Get in Touch