Prismaravon SovSec

Legal Vulnerability Disclosure Policy

SOV-LG-013

Vulnerability Disclosure Policy

Applies to Security researchers and the public · Version 1.0 · 2 November 2026

Draft — pending legal review. These documents are being finalised. Fields shown as [TO BE COMPLETED] are not yet filled in, and the wording may change before it is legally binding.

1. Our commitment

1.1 SovSec Ltd, a private limited company registered in England and Wales under company number [COMPANY NUMBER], registered office [REGISTERED OFFICE ADDRESS] — and, from the date on which it assumes the contract by written notice, its Austrian subsidiary [SOVSEC FLEXCO NAME], registered in the Austrian commercial register (Firmenbuch) under FN [FN NUMBER], Landesgericht [COURT], seat [ADDRESS, AUSTRIA] (planned 2028) (SovSec, we) builds the Prismara product suite and operates the SovSec and Prismara websites. We welcome reports from anyone who believes they have found a security vulnerability in them.

1.2 This Vulnerability Disclosure Policy (Policy) explains how to report, what we will do, and the conditions under which we consider research to be authorised. It is our coordinated vulnerability disclosure (CVD) policy.

1.3 Our process is designed to align with ISO/IEC 29147:2018 (vulnerability disclosure) and ISO/IEC 30111:2019 (vulnerability handling processes), and to meet the vulnerability-handling requirements for manufacturers in Regulation (EU) 2024/2847 (Cyber Resilience Act, CRA), Annex I Part II, and the reporting obligations in Art. 14 CRA. SovSec operates an integrated management system aligned to ISO/IEC 27001; it is not certified at the date of this Policy.

QUICK REFERENCE

Report to: security@sovsec.com · Encryption: age or OpenPGP key below · security.txt: https:// sovsec.com/.well-known/security.txt and https://prismara.eu/.well-known/security.txt · Acknowledgement: within 3 business days · Default disclosure: 90 days · Bounty: none at launch; recognition in our Hall of Fame.

2. Scope

2.1 This Policy covers:

In scope Examples

Prismara products (current Identity, Admin, Mail, Talk, Work, Spaces, Prism, Browser, OS, Core, Endpoint, SOC, ZTNA, Gov, supported versions) Crucible, Reach, Desk, CRM, HR, ERP, Cloud — web applications, APIs, desktop and mobile clients, agents, browser extensions, installers and update mechanisms

Prismara Personal services Personal Free and Personal Secure accounts, the name@prismara.eu mail service, the personal VPN service

Websites sovsec.com, sovsec.co.uk, prismara.eu, <app>.prismara.eu

Demo Sites (<app>- Vulnerabilities in the product code they run, and any way to reach other tenants, production systems or demo.prismara.eu) the underlying infrastructure from a Demo Site

Cryptography and supply Weaknesses in our hybrid post-quantum TLS or token signing implementation, signing keys, SBOM chain accuracy, build or update integrity

2.2 The following are out of scope. Do not test them; reports may be closed without action:

1. denial-of-service or load testing, volumetric attacks, and resource-exhaustion testing against production; 2. social engineering (including phishing) of SovSec staff, contractors, partners or clients, and any physical testing of premises, data centres or devices;

3. systems and data of our clients, partners and suppliers (for example our hosting provider), including a client's own Microsoft 365 tenant — report those to the owner; 4. on Demo Sites: the visibility of the fictional data or of entries made by other visitors, and the fact that Demo Sites can be reset — these are intended behaviour (but see clause 2.1 for genuine vulnerabilities in Demo Sites); 5. findings from automated scanners without a demonstrated, exploitable security impact; missing best-practice headers or cookie flags without impact; self-XSS; clickjacking on pages without sensitive actions; reports about software versions without a working exploit path; 6. issues that require a compromised device, physical access to an unlocked device, or a rooted/jailbroken device, unless the product claims to protect against that threat; 7. SPF/DKIM/DMARC configuration on non-sending domains, user enumeration on public sign-up flows where rate-limiting is in place, and rate-limit findings without a security impact; and 8. third-party services we link to, and vulnerabilities in third-party or open-source components that have not been shown to affect Prismara (please report those upstream; tell us if Prismara is affected).

2.3 If you are unsure whether something is in scope, ask us at security@sovsec.com before testing.

2.4 Spam, phishing, malware or other abuse sent from or hosted on Prismara services is not a vulnerability. Please report it to abuse@prismara.eu under our Acceptable Use Policy (SOV-LG-008).

3. Rules of engagement

3.1 To be covered by the safe-harbour statement in section 4, you must:

1. act in good faith, with the sole purpose of finding and reporting vulnerabilities; 2. use only accounts you own or that we have given you — create your own Prismara Personal Free account or test tenant, or use a Demo Site; never access another user's account or data; 3. stop as soon as you have shown that a vulnerability exists. If you encounter personal data, credentials, cryptographic keys or confidential information, do not view more than is needed to demonstrate the issue, do not copy, store, modify or delete it, and tell us immediately; 4. not degrade, disrupt or harm the Services, other users or our infrastructure, and not use automated tools at a rate that affects availability (as a guide, no more than [10] requests per second against any host); 5. not plant persistence, backdoors or malware, and not pivot to other systems after initial access; 6. not exploit the vulnerability beyond what is necessary, and not use it for any other purpose (including demanding payment); 7. report the vulnerability to us promptly (we ask within [7] days of discovery) and keep it confidential until we have published a fix or advisory or the disclosure date in section 7 has passed; and 8. comply with applicable law, including export and sanctions law.

3.2 Prismara Crucible (automated penetration testing) is a product, not a research channel: using Crucible against SovSec or Prismara systems is not permitted except under a Crucible authorisation (SOV-LG-011) that we have signed. Research under this Policy is governed by this Policy and our Acceptable Use Policy (SOV-LG-008).

4. Safe harbour

4.1 If you comply with this Policy, we consider your research to be authorised by SovSec, we will not initiate or support legal action against you in connection with it, and we waive restrictions in our terms (such as the Website

Terms of Use, SOV-LG-007, and the Acceptable Use Policy, SOV-LG-008) that would otherwise prohibit such research, to the extent needed for in-scope testing.

4.2 In particular, unauthorised access to a computer system under § 118a of the Austrian Criminal Code (StGB) is prosecuted only with the authorisation (Ermächtigung) of the injured party (§ 118a(3) StGB). We will not grant that authorisation, and will not file a criminal complaint (Anzeige) or join proceedings as a private party, in respect of research that complies with this Policy. We will not bring civil claims (for example under contract, copyright or unfair competition law) for such research.

4.3 Limits. Other offences (for example §§ 119, 119a, 126a–126c StGB) are prosecuted ex officio, and similar offences exist in other Member States; we cannot bind public prosecutors, courts, regulators or other third parties, and nothing in this Policy guarantees that no authority will act. Our authorisation covers only systems we control and does not extend to clients, partners or suppliers, or to conduct outside this Policy. If a third party takes legal action against you for research that complied with this Policy, we will, on request, confirm to the relevant authority that your research was authorised by us.

4.4 If in doubt about whether a planned test complies with this Policy, ask us first. If you have accidentally gone beyond this Policy, tell us straight away; we will take good faith into account.

4.5 Research involving personal data must also respect data protection law. We, as controller, treat the limited, incidental access permitted by item 3 of clause 3.1 as part of this authorised process, and we will handle the personal data in your report in accordance with our Privacy Policy (SOV-LG-005).

5. How to report

5.1 Email security@sovsec.com. Please encrypt sensitive details using one of our keys:

Method Key / location

age (preferred) age1[PUBLIC KEY — TO BE GENERATED] · published at https://sovsec.com/.well-known/age.txt

OpenPGP Fingerprint [FINGERPRINT — TO BE GENERATED] · https://sovsec.com/.well-known/pgp-key.txt; also via WKD for security@sovsec.com

security.txt (RFC https://sovsec.com/.well-known/security.txt and https://prismara.eu/.well-known/security.txt (signed; points to this 9116) Policy)

5.2 Our security.txt files will contain at least the following fields (RFC 9116):

Contact: mailto:security@sovsec.com Expires: [DATE — renewed at least yearly] Encryption: https://sovsec.com/.well-known/pgp-key.txt Policy: https://sovsec.com/security/vulnerability-disclosure Acknowledgments: https://sovsec.com/security/hall-of-fame Preferred-Languages: en, de Canonical: https://sovsec.com/.well-known/security.txt

5.3 Please include:

  • the product or website and version / build (or URL and timestamp with time zone);
  • the type of vulnerability (CWE if known) and your assessment of its impact and CVSS score (v3.1 or v4.0, with vector);
  • clear, step-by-step reproduction instructions and a proof of concept, ideally with screenshots, request/response pairs or a short video;
  • the accounts, tenants or test data you used, and any data you accessed;
  • whether the issue is publicly known or being exploited, and any disclosure deadline or conference talk you have planned;
  • how you would like to be credited (name, handle, link) or that you prefer to remain anonymous.

5.4 Anonymous reports are accepted. Do not include real personal data of other people in your report beyond what is strictly necessary.

5.5 You may also report a vulnerability to the national CSIRT designated as coordinator for coordinated vulnerability disclosure under Art. 12 of Directive (EU) 2022/2555 (NIS2) in your Member State (in Austria: [DESIGNATED CVD COORDINATOR — confirm, expected CERT.at]), which can act as a trusted intermediary.

6. What happens next — our timelines

6.1 We handle every report under our vulnerability handling process (ISO/IEC 30111 aligned): receipt, verification, remediation development, release and post-release review. We commit to the following:

Stage Target

Acknowledge receipt (with a tracking reference) Within 3 business days

Triage: confirm or reject, initial severity, expected timeline Within 10 business days

Status updates while the issue is open At least every 14 days, and when anything changes

Notify you before publication of the fix / advisory At least 5 business days before, where possible

6.2 We target the following remediation times from triage, based on the CVSS base score adjusted for the actual environment:

 Severity (CVSS)           Hosted services (SaaS)                                       Installed software (OS, Browser, clients, agents)

 Critical (9.0–10.0)       Mitigation within 48 hours; fix within 7 days                Fixed release within 14 days

 High (7.0–8.9)            Within 30 days                                               Within 30 days

 Medium (4.0–6.9)          Within 90 days                                               Next scheduled release, at most 90 days

 Low (0.1–3.9)             Within 180 days or next major release                        Next scheduled release

6.3 Actively exploited vulnerabilities are treated as critical regardless of score. Targets may be exceeded where a fix requires coordination with third-party or open-source maintainers; we will tell you why and agree a revised timeline.

6.4 Security updates for Prismara products are provided free of charge, separately from feature updates where technically feasible, and are accompanied by advisory messages telling users what to do (CRA Annex I Part II).

7. Coordination and public disclosure

7.1 We follow coordinated disclosure. The default embargo is 90 days from our acknowledgement, or until a fix is available and deployed or released, whichever is earlier. We may agree a different date with you, for example a short extension (normally up to 30 days) if a fix is close, or earlier publication if a fix is already deployed.

7.2 If a vulnerability is being actively exploited, or details become public, we may publish an advisory and mitigations sooner, and we will tell you before we do so.

7.3 After a fix, we publish a security advisory at https://sovsec.com/security/advisories (and in machine-readable CSAF 2.0 format) describing the vulnerability, affected and fixed versions, severity, impact, and remediation, and crediting you if you wish. For hosted services where no user action is needed, we may publish a summary advisory.

7.4 Please do not publish details before the agreed date. If we do not respond within the timelines in section 6 or cannot agree a date, please contact us again or the CSIRT referred to in clause 5.5 before publishing.

7.5 Where a vulnerability affects other vendors (for example an open-source component), we will coordinate with them and, where appropriate, with a national CSIRT. Under the CRA we will report vulnerabilities in components we integrate to the person or entity that maintains them.

8. CVE identifiers

8.1 We assign CVE identifiers to confirmed vulnerabilities in Prismara software that require user action or that affect released versions. SovSec intends to apply to become a CVE Numbering Authority (CNA) for Prismara. Until then, we request CVE IDs from an appropriate CNA — normally the CNA of Last Resort (MITRE) or, where a CSIRT coordinates the case, a CSIRT that is itself a CNA.

8.2 Vulnerabilities in purely hosted services that are fully fixed by us without user action may not receive a CVE, consistent with CVE programme rules; they are still listed in our advisories. We will tell you whether a CVE will be requested and include your credit in the CVE record if you wish.

9. Cyber Resilience Act reporting

9.1 Prismara software that we place on the EU market (for example Prismara OS, Browser, the Endpoint, Core and Reach agents, ZTNA clients, desktop and mobile apps, browser extensions, and the remote data processing solutions they rely on) are products with digital elements under the CRA, and SovSec is their manufacturer. Hosted functionality that is not part of such a product is outside the CRA; we apply the same process to it voluntarily.

9.2 From 11 September 2026, under Art. 14 CRA we notify actively exploited vulnerabilities and severe incidents having an impact on the security of those products, simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform:

 Report         Actively exploited vulnerability                                     Severe incident

 Early          Within 24 hours of becoming aware                                    Within 24 hours of becoming aware (including
 warning                                                                             whether unlawful or malicious acts are suspected)

 Notification   Within 72 hours of becoming aware, with general information,         Within 72 hours, with an initial assessment and
                corrective / mitigating measures taken and measures users can        the same information on measures
                take

 Final report   Within 14 days after a corrective or mitigating measure is           Within one month after the 72-hour notification
                available

9.3 The coordinator CSIRT is determined by Art. 14(7) CRA. While SovSec has no main establishment in the EU, this is the CSIRT of the Member State identified under that provision [to be confirmed; expected Austria, CERT.at, once the Austrian subsidiary is established].

9.4 After becoming aware of an actively exploited vulnerability or a severe incident, we also inform impacted users (and, where necessary, all users) of it and of any mitigations or corrective measures they can take, where appropriate in a structured, machine-readable format.

9.5 These reports concern our obligations as manufacturer; they do not disclose your identity without your agreement, except where the law requires it. Reporting to a CSIRT and ENISA does not change the embargo agreed with you, but a CSIRT may share information with other authorities as the CRA requires.

9.6 Separately, where a vulnerability leads to a personal data breach, we notify the competent data protection authority and affected individuals as required by the GDPR, and where we are an entity subject to NIS2 we report significant incidents under the applicable national law.

10. Support periods and SBOMs

10.1 Each major version of Prismara installed software receives security updates for at least 5 years from its first release, or longer where the product's expected use time is longer, in line with Art. 13(8) CRA. The end-of-support date of each version is published on the product's microsite and in its release notes, and stated at the time of purchase. Hosted services are continuously updated; only the current version is supported.

10.2 We maintain a software bill of materials (SBOM) for every Prismara release, covering at least top-level dependencies, in a machine-readable format (CycloneDX or SPDX). SBOMs are available to customers on request via support@sovsec.com and to market surveillance authorities on request. We may publish SBOMs for open- source components or Prismara OS images.

10.3 Releases and updates are signed. Signature verification keys and their fingerprints are published on our websites.

11. Recognition and rewards

11.1 We do not run a paid bug bounty programme at launch. We plan to introduce one after general availability of the Prismara suite and will announce it on our websites; it will not apply retrospectively unless we say so.

11.2 With your permission, we credit researchers in our advisories and CVE records and list them in our Hall of Fame at https://sovsec.com/security/hall-of-fame. Credit is given for valid, in-scope reports of a new vulnerability made in compliance with this Policy, and to the first reporter of each issue.

11.3 Requests for payment as a condition of disclosure, or threats to disclose, are not consistent with this Policy.

12. Changes and contact

12.1 We review this Policy at least annually and after significant changes to our products or the law. The current version is published at https://sovsec.com/security/vulnerability-disclosure. Reports are handled under the version in force when they are received, unless a later version is more favourable to you.

12.2 Questions about this Policy: security@sovsec.com. Legal questions: legal@sovsec.com.

Drafting notes — remove before publication

  • Generate and publish the age and OpenPGP keys, the signed security.txt files (both domains) and the advisories / Hall of Fame pages before publishing this Policy; replace [PUBLIC KEY], [FINGERPRINT], [DATE].
  • Remediation targets, the [10] req/s rate guide and the [7]-day reporting request are policy choices; confirm SovSec can meet them with current staffing (sole founder at launch).
  • CRA Art. 14 timelines and the 11 September 2026 start date were checked against secondary sources summarising Regulation (EU) 2024/2847 (Nov 2026); counsel to confirm against the Official Journal text, and to confirm which CSIRT is the coordinator under Art. 14(7) while SovSec Ltd has no EU main establishment (and whether an EU authorised representative should be appointed).
  • CRA scope: confirm with counsel which Prismara components are products with digital elements vs. pure SaaS, and whether any are 'important' or 'critical' products (Annex III/IV — e.g. browsers, password managers, VPNs, operating systems, endpoint security are listed categories), which affects conformity assessment from 11 December 2027.
  • CVE: confirm CNA application route (MITRE or a Root) and current CVE programme rules on cloud-service vulnerabilities before relying on clause 8.2.
  • § 118a(3) StGB Ermächtigungsdelikt checked against a secondary source of the current text; Rechtsanwalt to confirm, and to confirm the designated CVD coordinator under NIS2 Art. 12 in Austria.
  • Confirm a German translation of this Policy for publication alongside the English version.

End of SOV-LG-013 Vulnerability Disclosure Policy v1.0 (EU edition). SovSec Ltd · Company no. [COMPANY NUMBER] (England and Wales) · VAT no. [UK VAT] · EU OSS / UID [NUMBER]; from 2028: [SOVSEC FLEXCO NAME], FN [FN NUMBER], UID ATU[NUMBER].

Questions about this document? Contact us. SovSec Ltd — Sovereignty is Security.

Prismara

Bei Ihrem Arbeitsbereich anmelden

oder

Passwort und zweiten Faktor geben Sie nur auf der Seite von Prismara Identity ein, nie hier. Administratoren nutzen den Admin-Login.
Prismara Admin-Konsole

Anmeldung für Administratoren

Passkey erforderlich
Eigene Sitzung, getrennt von Ihrem Benutzerkonto
Jede Aktion wird im Audit-Trail erfasst
oder

Weiter zu Prismara Admin unter admin.prismara.eu. Kein Administrator? Nutzen Sie den Benutzer-Login.