Product Security
and the EU Cyber Resilience Act
CRA Compliance and Supplier Audit File
If you build a product that reaches the European market and you embed ProEssentials in it, the EU Cyber Resilience Act makes you responsible for the security of every component you integrate. This page exists so you can satisfy that responsibility with respect to ProEssentials without having to send us a questionnaire.
All supported versions of ProEssentials contain no third-party or open-source code, open no network connections, and handle no customer data at runtime. No security exploit has ever been reported in ProEssentials itself in more than 25 years of shipping. Every distribution we publish is cryptographically signed, and security fixes are free of charge for every version inside its published support period.
Need a document rather than a web page? Download the ProEssentials EU CRA Statement (PDF). Same content as this page, ready to attach to your audit file.
Security tooling has improved faster than people have. AI and automated scanners now find vulnerabilities better than any human review, and attackers have the same tools we do, so we have to work harder at hardening than we used to. That cuts in one clear direction: a component with almost no dependencies, that never talks back and forth to the internet, is the safest thing you can embed. There is very little for a scanner, or an attacker, to point at.
Which brings us to the awkward part. In our experience, large companies are reluctant to move to a new version, or even to the latest version they already own, simply because they are wary of the testing. Please trust us not to break your code. We try hard not to, and we probably try harder than any other component vendor to make upgrading frictionless. Skipping many versions may mean tweaking a few fonts and colors; minor version upgrades rarely need even that. Please use the latest version you have purchased, and keep your code current.
What you can rely on
The commitments on this page are the ones a compliance reviewer normally has to ask for. They are stated here so you can file them directly.
| Third-party and open-source code | None in any supported version. Verified by inspecting the shipped binaries. Versions 8 and earlier are a documented exception; see below. |
|---|---|
| Network activity | The component opens no network connections and phones nothing home. |
| Customer data | Gigasoft neither transmits, receives, nor stores any of your data through the product at runtime. |
| Support period | Five years minimum per major version, with a published end date. |
| Security updates | Provided free of charge for the duration of the support period. |
| Vulnerability reporting | support@gigasoft.com, monitored, with a two-business-day acknowledgement target. |
| Distribution integrity | Installers are Authenticode signed; NuGet packages carry a Gigasoft author signature. |
| Reported security incidents | None in the product's history. |
Where ProEssentials sits in your CRA obligations
Under the Cyber Resilience Act, the company that places a finished product on the EU market is its manufacturer, and Article 13(5) requires that manufacturer to exercise due diligence on the third-party components it integrates, so that those components do not compromise the security of the finished product. If you ship an application containing ProEssentials, that duty is yours and ProEssentials is one of those components.
Practically, this means your audit file needs to show that you evaluated ProEssentials and that its supplier has a real vulnerability-handling process behind it. This page is written to be that evidence. Everything below is stated plainly enough to quote, and we will confirm any of it in writing on company letterhead if your process requires a signed supplier statement.
Article 13(6) also requires you to tell us when you find a vulnerability in a component you have integrated. We commit to the same duty in reverse, and we would much rather hear from you early than late. Reports go to support@gigasoft.com.
The part that matters most: there is almost nothing to audit
Most of the effort in a modern software supply-chain review goes into dependencies. A charting library that pulls in dozens of packages hands you dozens of components you now own: each one needs to appear in your bill of materials, each one needs monitoring for new CVEs, and each one can force an unplanned release when a vulnerability lands upstream.
ProEssentials does not work that way. In every supported version, all ProEssentials code is proprietary and was written by Gigasoft, with no open-source libraries, no third-party NuGet or npm packages, and no vendored code from any outside source. The whole class of dependency-chain incidents, the Log4Shell pattern, does not reach you through us. That is not a claim we ask you to take on trust: we verified it by inspecting the shipped binaries.
Three further properties reduce your exposure to roughly nothing:
- No network I/O. The component neither initiates nor terminates network connections. There is no telemetry, no licence check-in, no update ping, and no outbound traffic of any kind.
- No data handling by Gigasoft. Your data is charted inside your own process, on your own machine. Gigasoft does not transmit, receive, or store any of it at runtime.
- No account, no activation, no runtime service. Deployment is a file copy. There is no cloud dependency to assess and no third-party service in the data path.
One boundary worth stating explicitly, because auditors ask: encryption in transit for any data that your application moves over a network is the responsibility of your application. ProEssentials never sees a network, so it can neither protect nor endanger data in transit.
Bill of materials
Because a supported version has no third-party components, our bill of materials is short enough to print in full. A ProEssentials deployment consists of the Gigasoft-authored rendering engine, the Gigasoft-authored control assembly for your chosen framework, and nothing else. Everything else your application loads is either your own code or an in-box part of the operating system or of the .NET or Windows App SDK runtime you already ship.
Legacy version 8 and earlier third-party libraries
Early ProEssentials statically linked three open-source libraries to only write image files: zlib for compression, libpng for PNG output, and libjpeg for JPEG output. At the time this was ordinary practice as Windows did not yet provide image encoders of its own.
| ProEssentials version | Third-party libraries in the shipped engine |
|---|---|
| Versions 3 through 8 | zlib 1.1.3, 1.2.3, libpng 1.2.40, and libjpeg, statically linked, no reading/decoding, encode only |
| Version 9 and later | None. Image encoding uses the Windows imaging components. |
No security exploit has ever been reported to us in any version of ProEssentials.
Again, these libs were never used to read or decode a file, which is where this class of vulnerability lives, nothing was ever decompressed, and no ProEssentials API ever exposed a decode path to a caller. There is no realistic vulnerability in how earlier ProEssentials used these libs.
Our recommendation is to move to version 11. Version 8 and earlier are end of life and will not be updated. The API has been kept deliberately stable across major versions, porting is easy.
CRA timeline, and what it means for you
The Cyber Resilience Act, Regulation (EU) 2024/2847, applies in phases. We would rather give you the dates than a blanket assurance.
| 10 December 2024 | The Regulation entered into force. No product obligations yet. |
|---|---|
| 11 June 2026 | Provisions on the notification of conformity assessment bodies began to apply. |
| 11 September 2026 | Reporting obligations under Article 14 begin: actively exploited vulnerabilities and severe incidents must be reported to the relevant CSIRT and ENISA, with an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days for a vulnerability or one month for a severe incident. |
| 11 December 2027 | The main obligations apply in full: secure design and development, vulnerability handling across the support period, technical documentation, conformity assessment, and CE marking. |
Gigasoft is on track for these dates. The substance of what the Regulation asks of a component like ours is already in place and described on this page: no unmanaged dependency surface, a defined support period, security updates at no cost, a published reporting channel, and signed distributions. The remaining work between now and December 2027 is formal documentation and conformity paperwork, not a change to how the product is built.
We will keep this page current as the framework develops, including the harmonised standards that are still being finalised.
How ProEssentials classifies under the CRA
The Regulation treats a software component that is placed on the market separately as a product with digital elements in its own right, so ProEssentials is in scope and not merely an ingredient of your product.
ProEssentials is a default-category product. It does not match any of the nineteen Annex III Class I categories or the four Annex III Class II categories, and it is not an Annex IV critical product. A charting and data-visualization library for developers performs none of the core functions that place a product in those classes, and we have checked our classification against the technical definitions in Commission Implementing Regulation (EU) 2025/2392.
The practical consequence for you: ProEssentials follows the internal-control conformity assessment route under Article 32(1) and Annex VIII Module A. No notified body is involved, and no third-party assessment is required for a component of this type. If your own product falls into a higher class, that classification is driven by your product's function, not by ours.
Supported versions and support period
The Cyber Resilience Act expects a manufacturer to state a support period and to publish when it ends, rather than leaving it open. Ours is at least five years for each major version, measured from that version's general availability date. We would also rather tell you what a version actually gets than label everything equally supported, so the table separates active development from maintenance and from critical-security-only.
| Version | Status | Security updates through |
|---|---|---|
| ProEssentials v11 | Active development. Security fixes plus ongoing tweaks, additions and improvements. Recommended for all new and existing work. | At least 21 July 2031 |
| ProEssentials v10 | Maintenance. Security and critical fixes; feature work is winding down. | At least 23 January 2030 |
| ProEssentials v9 | Critical security only. A major security issue would be addressed; nothing else. | No dated commitment |
| ProEssentials v8 and earlier | End of life. Not receiving updates. | Not applicable |
ProEssentials v11 reached general availability on 21 July 2026 and v10 on 23 January 2025, so their published support periods run to at least 21 July 2031 and 23 January 2030 respectively. Version 9 first shipped in April 2018, which places it beyond that five-year window, so we make no dated commitment for it and would act only on a critical security issue. Customers on version 9 should plan a move to version 11.
Reporting a vulnerability, and what happens next
If you believe you have found a security vulnerability in ProEssentials, send it to support@gigasoft.com. Please include the product version, the framework and platform, and enough detail to reproduce the issue. A proof of concept helps but is not required.
What we commit to:
- We acknowledge a report within two business days.
- We assess it and tell you whether we can reproduce it, with an initial severity view, within ten business days.
- We fix confirmed vulnerabilities without undue delay, prioritised by severity, and we tell you our intended timing rather than leaving you guessing.
- Security fixes are free of charge for every supported version, and are issued separately from feature releases where doing so serves customers better.
- We notify affected customers directly and publish the fix through the normal update channels.
- We will credit you if you want credit, and we will not pursue good-faith security research. We ask only that you give us a reasonable chance to issue a fix before public disclosure.
We are a small, direct company. A report sent to that address reaches the people who wrote the code, not a ticket queue.
How patches and updates reach you
Security and maintenance fixes are distributed through the same channels as ordinary releases, so there is no separate process for you to learn.
- Maintenance patches are published on our downloads page for direct download.
- NuGet packages are updated for the .NET WinUI, WPF, and WinForms flavours.
- Full installers are refreshed for customers who deploy from setup.
Because ProEssentials deploys as a file copy with no activation and no runtime service, applying an update is a matter of replacing the binaries you already ship. There is nothing to reactivate and no licence server to coordinate with.
Distribution integrity and code signing
Every channel we publish through is signed, so you can verify that what you received is what we built:
- Installers are Authenticode code-signed as Gigasoft, Inc. Signing uses SHA-256 with RFC 3161 trusted timestamping, and the uninstaller is signed as well.
- NuGet packages carry a Gigasoft, Inc. author signature. You can verify it yourself with the standard tooling: run dotnet nuget verify against the package and check that the author signature names Gigasoft, Inc.
One limitation we would rather state than have you discover. The individual binaries inside a distribution are not separately Authenticode signed. This is deliberate and technical: per-customer licence stamping rewrites bytes inside the engine when your product is installed, which would invalidate any signature applied to that file beforehand. Integrity is therefore assured at the package level, where the signature covers the whole distribution, rather than per file. If your compliance process specifically requires per-file signatures, contact us and we will discuss what we can do for your case.
Secure development and company practices
Gigasoft is a small, focused company, and we would rather describe our practices accurately than borrow the vocabulary of a large enterprise security programme.
- Security is owned at the top. The company principal is personally responsible for security decisions. Nothing is delegated to a function that does not exist.
- All product code is our own. Every line is written and reviewed in-house, which is why there is no dependency chain to monitor.
- Inputs are validated and database access is parameterised. This covers the company systems that support the product, such as registration and downloads.
- Company systems are hardened at multiple layers. That includes the website and web server, email authentication, and endpoint protection. Email is protected by SPF, DKIM, and an enforcing DMARC policy, which you can verify independently against our DNS records. We do not publish our specific configurations, because doing so would help an attacker more than it helps you.
- Server logs are reviewed for abuse patterns. Abuse controls also operate at the web tier.
- Endpoints run current Windows with Microsoft Defender.
We are equally clear about what we are not. We do not operate enterprise network infrastructure, so controls such as deep packet inspection or intrusion detection on encrypted traffic are not part of our profile and would be theatre if we claimed them. We do not store customer data for the product, because the product does not send us any. If a questionnaire asks about a control that does not apply to a small component vendor whose product runs entirely inside the customer's own environment, we will say so and explain why rather than answering to the template.
What we will supply for your audit file
On request to support@gigasoft.com, at no cost:
- A machine-readable SBOM in SPDX or CycloneDX format for your version.
- A signed supplier security statement on company letterhead, confirming the commitments on this page.
- Written answers to your own vendor security questionnaire.
- Confirmation of the support-period end date, and the current support level, for the version you have deployed.
- Our coordinated vulnerability disclosure commitments, as set out above.
We have been through enterprise security assessments for customers in regulated industries and we know what the process needs. Ask for what your reviewer requires and we will produce it.
Frequently asked questions
What does a CVE search for ProEssentials show?
No real-world or exploited vulnerabilities have ever been reported for ProEssentials.
In 2018, a theoretical vulnerability (CVE-2017-7908, which records v5 though the affected OCX was v4, 2002) was documented. It identified a conceptual heap-based buffer overflow in the legacy ActiveX controls of ProEssentials Version 4 from 2002 and earlier. This theoretical exploit required a user to local-load a highly customized, malicious HTML file. It was never successfully achieved or exploited in the wild.
The underlying defect was a single unchecked string copy, one strcpy that should have been strncpy. It sat in the ActiveX wrapper rather than in our Win32 rendering DLL, which is part of why we missed it. The core Win32 rendering engine used by our .NET, WinForms, WPF and WinUI customers was never affected.
The browser landscape had closed this off independently. From Internet Explorer 7 (2006), any ActiveX control not on Microsoft's pre-approved list required explicit user consent before it would load, and IE8 (2009) added a second prompt whenever a control was loaded by a site other than the one that installed it, specifically to stop a malicious page reusing a control this way. Chrome, Firefox and Safari never supported ActiveX at all, and Edge dropped it in 2015.
Furthermore, the third-party software that bundled this legacy version (GE Communicator 3.15) had already been updated by GE before this advisory was published.
A search for CVEs related to ProEssentials does show one old hit, but otherwise a flawless security record across decades of versions and active enterprise deployment.
While many of our competitors frequently show recent CVE vulnerabilities stemming from their reliance on third-party dependencies, ProEssentials is built entirely from the ground up. Because ProEssentials contains zero external dependencies, we eliminate the supply-chain security risks that commonly compromise other charting components.
If you happen to search GE Vernova's Communicator and Energy Aggregator, you will find ProEssentials still inside GE software. GE has been using Gigasoft for more than twenty years, thank you GE, we appreciate it.
Will Gigasoft comply with the EU Cyber Resilience Act?
Yes. Gigasoft is on track for the CRA dates, and the substance of what the Regulation requires of a component like ProEssentials is already in place: no third-party dependency surface, a defined and published support period, security updates free of charge, a monitored vulnerability reporting channel, and signed distributions. The main obligations apply from 11 December 2027 and the Article 14 reporting obligations from 11 September 2026; the work remaining on our side between now and then is formal documentation and conformity paperwork rather than changes to how the product is built.
Does ProEssentials contain any open-source or third-party code?
Not in any supported version. In version 9 and later, all ProEssentials code is proprietary and was written by Gigasoft: no open-source libraries, no third-party NuGet or npm packages, no vendored outside code. We verified this by inspecting the shipped binaries, not from memory. This removes an entire category of supply-chain risk from your product, along with any open-source licence compliance exposure.
Can you provide a software bill of materials?
Yes. Because there are no third-party components, the bill of materials is very short: the Gigasoft rendering engine, the Gigasoft control assembly for your framework, and nothing else. A formal machine-readable SBOM in SPDX or CycloneDX format is available on request from support@gigasoft.com.
Does ProEssentials make network connections or send any data to Gigasoft?
No. The component neither initiates nor terminates network connections. There is no telemetry, no licence check-in, and no update ping. Gigasoft does not transmit, receive, or store any of your data through the product at runtime. Your data is charted inside your own process on your own machine.
How do I report a security vulnerability?
Email support@gigasoft.com with the product version, framework, platform, and reproduction details. We acknowledge within two business days, give you a reproduction and severity assessment within ten business days, and fix confirmed vulnerabilities without undue delay. We credit reporters who want credit and we do not pursue good-faith security research.
How long will my version receive security updates?
At least five years from a major version's general availability date. ProEssentials v11 became generally available on 21 July 2026, so it is covered through at least 21 July 2031, and v10 on 23 January 2025, covered through at least 23 January 2030. Version 9 is past its five-year window and now receives fixes only for a critical security issue.
Which versions of ProEssentials are supported?
Three, at different levels. Version 11 is in active development: security fixes plus ongoing tweaks, additions and improvements. Version 10 is in maintenance, receiving security and critical fixes through at least 23 January 2030, with feature work winding down. Version 9 is past its five-year window and receives fixes only for a critical security issue. Version 8 and earlier are end of life, no longer built or updated. If your compliance programme requires a component under active development, move to version 11.
Are your binaries code-signed?
Our distributions are. Installers are Authenticode signed as Gigasoft, Inc. with SHA-256 and RFC 3161 timestamping, and NuGet packages carry a Gigasoft, Inc. author signature that you can verify with dotnet nuget verify. The individual binaries inside a distribution are not separately signed, because per-customer licence stamping rewrites bytes in the engine at install time and would invalidate any prior per-file signature. Integrity is assured at the package level.
Is ProEssentials an important or critical product under CRA Annex III or Annex IV?
No. ProEssentials is a default-category product. It matches none of the nineteen Annex III Class I categories, none of the four Annex III Class II categories, and it is not an Annex IV critical product. It therefore follows the internal-control conformity assessment route under Article 32(1) and Annex VIII Module A, with no notified body involved. Your own product's classification is determined by your product's function, not by ours.
What exactly do I need from Gigasoft for my Article 13(5) due diligence?
For most reviewers this page is sufficient, because it documents the component's composition, its runtime behaviour, the support period, the vulnerability handling process, and the integrity of the distribution. If your process requires more, request a signed supplier security statement, an SBOM for your version, or written answers to your own questionnaire from support@gigasoft.com, and we will provide them at no cost.
Will you provide patches for vulnerabilities you discover or that are reported to you?
Yes. Confirmed vulnerabilities are fixed without undue delay and prioritised by severity, for every supported version. Security fixes are free of charge, distributed through the downloads page, NuGet, and refreshed installers, and issued separately from feature releases where that serves customers better. We notify affected customers directly.
Talk to us
Security questions, questionnaires, document requests, and vulnerability reports all go to support@gigasoft.com and reach the people who build the product.
This page was last reviewed on 30 July 2026 and is maintained as the CRA framework develops.
This page describes Gigasoft's product security practices and our understanding of how the Cyber Resilience Act applies to ProEssentials. It is provided to support your own compliance work and is not legal advice. Your obligations for the product you place on the market are determined by your product, your market, and your own assessment.
Our Mission
Your success is our #1 goal by providing the easiest and most professional benefit to your organization and end-users.
We are Engineers
ProEssentials was born from professional Electrical Engineers needing their own charting components. Join our large list of top engineering companies using ProEssentials.
Thank You
Thank you for being a ProEssentials customer, and thank you for researching the ProEssentials charting engine.