Document Version: 1.0 Last Updated: 2026-04-28
CRANIS2 is a compliance platform that helps software companies meet the requirements of the EU Cyber Resilience Act (CRA) and the NIS2 Directive. It connects to your existing source code repositories and automatically builds the compliance evidence that regulators expect to see. The platform automates seven compliance functions: SBOM management, vulnerability monitoring, license compliance, intellectual property proof, CRA technical documentation, ENISA reporting, and source code escrow. CRANIS2 reads dependency metadata from your repositories but never stores, analyses, or modifies your source code.
See the User Guide, Section 1: Introduction for a full overview.
CRANIS2 stands for Cyber Resilience Act and NIS2. The name reflects the two major pieces of EU legislation that the platform addresses: the Cyber Resilience Act (CRA) and the Network and Information Security Directive (NIS2). Together, these regulations form the backbone of the EU's approach to cybersecurity for software products and critical infrastructure.
CRANIS2 is designed for four audiences:
In practice, any company that manufactures, imports, or distributes software products with digital elements in the EU market will benefit from the platform. See the User Guide, Section 1: Introduction.
No. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. If your company sells software to customers in the EU -- even if your headquarters are in the United States, United Kingdom, or elsewhere -- you are subject to CRA requirements and CRANIS2 can help you meet them. Companies based outside the EU may also need to designate an authorised representative within the EU.
See the User Guide, Section 2: Regulatory Context.
CRANIS2 offers two pricing tiers:
An active contributor is anyone who has made at least one contribution to a connected repository. Bot accounts are automatically identified and excluded from billing. You can upgrade or downgrade at any time from the Billing page; Stripe handles proration automatically.
See the User Guide, Section 18: Billing.
Yes. Every new organisation receives a 30-day free trial (extended to 90 days with a bonus code at signup) with full Pro-tier access to all platform features. No credit card is required to start the trial. You can register products, connect repositories, generate SBOMs, run vulnerability scans, use the AI Copilot, and use every feature during the trial period without restriction.
See the User Guide, Section 18: Billing.
The free trial lasts 30 days from the date your organisation is created (extended to 90 days if you enter a bonus code at signup). After the trial expires, there is an additional 7-day grace period during which you retain full access but see a warning banner prompting you to subscribe. After the grace period, the account enters read-only mode. You can subscribe at any point during the trial or grace period to continue with uninterrupted access.
See the User Guide, Section 18: Billing.
The CRA is an EU regulation that entered into force in December 2024. It applies to any product with digital elements placed on the EU single market and imposes cybersecurity requirements across the entire product lifecycle -- from design through end-of-support. The regulation affects manufacturers, importers, distributors, and open source stewards. Penalties for non-compliance can reach up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.
See the User Guide, Section 2: Regulatory Context.
The CRA follows a phased timeline:
Organisations should begin preparing now, particularly for the September 2026 reporting deadline. See the User Guide, Section 2: Regulatory Context.
The penalties are significant:
See the User Guide, Section 2: Regulatory Context.
A Technical File is the documentation package that CRA Annex VII requires manufacturers to maintain for every product with digital elements. It must be available on request to market surveillance authorities and serves as the primary evidence of your compliance. The file covers eight sections that document everything from product design to conformity declarations. CRANIS2 provides structured editors for all eight sections.
See the User Guide, Section 9: Technical Files.
The eight Annex VII sections are:
Each section has a content editor, internal notes field, and status indicator. See the User Guide, Section 9: Technical Files.
The CRA classifies products into three categories based on cybersecurity risk:
See the User Guide, Section 2: Regulatory Context.
The CRA and NIS2 are complementary. The CRA focuses on product security -- requiring that software products meet cybersecurity standards. NIS2 focuses on organisational security -- imposing obligations on entities operating critical infrastructure (energy, transport, banking, health, digital infrastructure, and more). If your organisation falls under NIS2 and you also manufacture software products, both sets of obligations apply. CRANIS2 tracks obligations from both frameworks in a unified view.
See the User Guide, Section 2: Regulatory Context.
ENISA is the European Union Agency for Cybersecurity. Under CRA Article 14, manufacturers must report actively exploited vulnerabilities and severe security incidents to both ENISA and their national CSIRT on a strict timeline. ENISA coordinates the EU-wide response to cybersecurity threats. CRANIS2 automates deadline tracking, provides structured reporting forms, and monitors deadlines hourly to ensure you never miss a filing window.
See the User Guide, Section 10: ENISA Reporting.
A CSIRT (Computer Security Incident Response Team) is the national cybersecurity body in each EU member state. Every EU country has a designated CSIRT responsible for coordinating responses to cybersecurity incidents. When filing an ENISA report, you must identify the CSIRT of the member state where the impact is felt. CRANIS2 includes an EU27 country selector for this purpose.
See the User Guide, Section 10: ENISA Reporting.
CRANIS2 helps you prepare the documentation and evidence required for CE marking. This includes the complete Technical File (all eight Annex VII sections), the Annex I Part I checklist (13 essential cybersecurity requirements), conformity assessment documentation, and the Declaration of Conformity. The platform tracks completion of each section and highlights where gaps remain. The actual CE mark application and affixing is a separate regulatory process that you complete with the relevant authorities.
See the User Guide, Section 9: Technical Files.
There are three mandatory reporting stages with strict deadlines:
| Stage | Deadline | Content |
|---|---|---|
| Early Warning | 24 hours after awareness | Summary, initial assessment, malicious action suspected? |
| Notification | 72 hours after awareness | Detailed description, corrective measures, patch status |
| Final Report | 14 days (vulnerability) or 1 month (incident) | Root cause, severity, preventive measures |
These deadlines are legally binding from September 2026. CRANIS2 calculates all three deadlines automatically from the awareness date you provide. See the User Guide, Section 10: ENISA Reporting.
An SBOM (Software Bill of Materials) is a machine-readable inventory of all software components in a product -- including direct dependencies, transitive dependencies, their versions, ecosystems, and licenses. CRA Article 13 requires manufacturers to maintain an SBOM for every product with digital elements. The SBOM enables vulnerability tracking (which components are affected by known CVEs), license compliance verification (are all licenses compatible with your distribution model), and supply chain transparency (what exactly is in your product). CRANIS2 generates and maintains SBOMs automatically from your connected repositories.
See the User Guide, Section 14: Repository Management and Section 16: Dependencies.
Navigate to the signup page and provide a valid email address and a password that meets all five strength criteria: at least 8 characters, at least one uppercase letter, at least one lowercase letter, at least one number, and at least one special character. A strength meter on the signup form shows your progress in real time. After signing up, you will receive a verification email from info@poste.cranis2.com.
See the User Guide, Section 3: Getting Started.
First, check your spam or junk folder -- the email comes from info@poste.cranis2.com and may be filtered by your email provider. If the email does not arrive within a few minutes, try signing up again with the same email address. Until your email is verified, you will not be able to log in or access the platform. If problems persist, submit a support request describing the issue.
See the User Guide, Section 3: Getting Started.
After email verification and first login, you are directed to a Welcome page that introduces the platform and guides you to create your organisation. The setup wizard collects your organisation name, country, company size (Micro, Small, Medium, or Large), CRA role (Manufacturer, Importer, Distributor, or Open Source Steward), and optionally your industry. Your CRA role determines which obligations are tracked and how compliance workflows behave. Most software companies should select Manufacturer.
See the User Guide, Section 3: Getting Started.
Yes. Organisation settings such as name, country, company size, CRA role, and industry can be updated at any time from the Organisation page under Settings in the sidebar. Changing your CRA role may affect which obligations are tracked for your products.
See the User Guide, Section 21: Organisation Management.
Navigate to the Stakeholders page under Settings in the sidebar. From there you can invite new members by their email address. Invited users receive an email with instructions to create an account (if they do not already have one) and join your organisation. You can assign roles and manage team member access from the same page.
See the User Guide, Section 20: Stakeholders.
An admin has full control over the organisation, including managing members, configuring products, accessing billing settings, and modifying organisation-level configuration. A member can work within the platform -- reviewing findings, updating technical files, filing reports, and managing product-level data -- but cannot manage organisation settings, billing, or user access. The person who creates the organisation is automatically assigned the admin role.
See the User Guide, Section 20: Stakeholders.
Navigate to the Products page and click the create button. The creation form collects the product name, product type, and CRA category (all required), plus optional fields for description, version, repository URL, and distribution model. Once created, you can connect a repository, begin filling the Technical File, and start building compliance evidence.
See the User Guide, Section 5: Products.
Most software products fall under Default, which allows self-assessment by the manufacturer. Choose Class I (Important) if your product falls into categories such as identity management, VPNs, network management tools, firewalls, or intrusion detection systems. Choose Class II (Critical) only for products such as operating systems, hypervisors, hardware security modules, or smartcard readers. When in doubt, consult CRA Annex III (Class I) and Annex IV (Class II) for the full product lists, or seek legal advice.
See the User Guide, Section 2: Regulatory Context.
CRANIS2 supports eight product types: Firmware, SaaS, Library, Desktop App, Mobile App, IoT, Embedded, and Other. The product type helps categorise your portfolio and is informational. Your distribution model (a separate field) has a more direct impact on compliance analysis, particularly for license compatibility.
See the User Guide, Section 5: Products.
There are five distribution models, each affecting license compatibility analysis differently:
| Model | Description |
|---|---|
| Proprietary Binary | Distributed as compiled binary without source code |
| SaaS Hosted | Hosted as a service -- users do not receive a copy |
| Source Available | Source code available under restrictive terms |
| Library Component | Distributed as a library for integration by others |
| Internal Only | Used internally, not distributed to third parties |
See the User Guide, Section 5: Products.
From the product detail page, click Connect Repository. For GitHub, Codeberg, and Bitbucket Cloud, an OAuth popup flow handles authentication -- you authorise CRANIS2 and select your repository. For self-hosted Gitea, Forgejo, or GitLab instances, you first establish a PAT connection on the Repos page, then connect individual products to repositories on that instance. The first SBOM sync begins automatically after connection.
See the User Guide, Section 14: Repository Management.
Yes. You can create a product and work on its Technical File, obligations, and other compliance documentation without ever connecting a repository. However, the automated compliance features -- SBOM generation, vulnerability scanning, license compliance analysis, and IP proof -- all depend on a connected repository. Products without a repository will require manual compliance evidence.
See the User Guide, Section 5: Products.
Product details including name, description, version, type, CRA category, and distribution model can all be edited from the product detail page. Navigate to the product and update the fields as needed. Note that changing the distribution model may affect license compatibility verdicts for existing dependencies.
See the User Guide, Section 5: Products.
When you delete a product, CRANIS2 generates a data exit package -- a ZIP file containing all compliance data associated with that product. This includes the SBOM, vulnerability findings, technical file content, reports, and other evidence. The data exit ensures you retain your compliance evidence even after removing the product. If the product had escrow enabled, the Forgejo repository is preserved even after deletion, in accordance with legal retention requirements.
See the User Guide, Section 5: Products.
CRANIS2 reads dependency metadata from your repositories but never stores, analyses, or modifies your source code. During SBOM generation, repository contents are accessed via the provider's API, parsed in memory, and only the resulting dependency metadata is persisted. Source files are not written to disk, cached, or transmitted to any third party. This applies to all three SBOM generation tiers, including the import scanner.
See the User Guide, Section 14: Repository Management.
CRANIS2 stores the following from your repository:
It does not store source code files, commit diffs, file contents, or any proprietary business logic. See the User Guide, Section 14: Repository Management and Section 16: Dependencies.
During Tier 3 import scanning, CRANIS2 retrieves source files via the repository provider's API, scans them in memory for import statements (import, require, use, include, and equivalents across 26 languages), extracts the dependency names, and immediately discards the source content. Only the identified dependency names are persisted. The scanner operates within strict memory guards to prevent resource exhaustion. No source files are written to disk at any point.
See the User Guide, Section 14: Repository Management.
Personal Access Tokens for self-hosted providers (Gitea, Forgejo, GitLab) are encrypted at rest before being stored in the database. CRANIS2 validates each token against the provider's API before accepting it, confirming that it grants the expected permissions. OAuth tokens for GitHub and Codeberg follow standard OAuth security practices. Tokens are used exclusively for API calls to the connected provider and are never exposed to other users, logged in plaintext, or transmitted to third parties.
See the User Guide, Section 14: Repository Management.
Yes. Disconnecting a repository is immediate and removes the live connection. All previously generated compliance data is preserved -- the existing SBOM, vulnerability findings, license scan results, and IP proof snapshots remain intact and continue to be available. Only future automatic syncs are stopped. You can reconnect the same repository or connect a different one at any time.
See the User Guide, Section 14: Repository Management.
CRANIS2 supports six repository providers:
| Provider | Auth Method | Hosting |
|---|---|---|
| GitHub | OAuth (popup flow) | github.com |
| Codeberg | OAuth (popup flow) | codeberg.org |
| Bitbucket Cloud | OAuth | bitbucket.org |
| Gitea | Personal Access Token | Self-hosted instances |
| Forgejo | Personal Access Token | Self-hosted instances |
| GitLab | Personal Access Token | Self-hosted instances |
See the User Guide, Section 14: Repository Management and Appendix B: Supported Repository Providers.
Navigate to the product detail page and click Connect Repository. Select GitHub or Codeberg as the provider. A popup window opens where you authorise CRANIS2 to access your repositories. Once authorised, select the specific repository from the list. The connection is established immediately and the first SBOM sync begins automatically.
See the User Guide, Section 14: Repository Management.
Navigate to the Repos page and open the Provider Connections panel. Select the provider type (Gitea, Forgejo, or GitLab), enter the instance URL (e.g. https://git.example.com), and provide a Personal Access Token generated from your provider's account settings. CRANIS2 validates the token against the provider's API before storing it. Once validated and encrypted, you can connect individual products to repositories on that instance.
See the User Guide, Section 14: Repository Management.
A PAT is an authentication credential generated from your repository provider's account settings. It grants CRANIS2 the permissions needed to read repository metadata, dependency files, contributor information, and release data. The token should be configured with read-only repository access at minimum. CRANIS2 encrypts the token at rest and uses it exclusively for API calls to the connected instance. It never writes to your repository.
See the User Guide, Section 14: Repository Management.
Yes. Once you have established an OAuth connection (GitHub, Codeberg, Bitbucket Cloud) or a PAT connection (Gitea, Forgejo, GitLab), you can connect any number of repositories from that provider to different products. Each product is linked to one repository, but your provider connection can serve as many products as you need. You only need to authenticate once per provider instance.
CRANIS2 uses a three-tier fallback approach. It attempts each tier in order and uses the first successful result:
See the User Guide, Section 14: Repository Management.
Tier 1 (API SBOM) is the fastest and relies on GitHub's own analysis, but is only available for GitHub-hosted repositories. Tier 2 (Lockfile Parsing) produces the most precise SBOMs because lockfiles contain exact, resolved dependency versions including all transitive dependencies. Tier 3 (Import Scanning) is a best-effort approach -- it identifies dependencies from import statements but cannot determine exact versions or capture dependencies that are not explicitly imported in source code.
See the User Guide, Section 14: Repository Management.
CRANIS2 supports 28 lockfile formats across all major ecosystems, including:
The full list is in the User Guide, Appendix C: Supported Lockfile Formats.
Import scanning (Tier 3) supports 26 programming languages, including JavaScript, TypeScript, Python, Rust, Go, Java, Kotlin, C#, Ruby, PHP, Swift, Dart, Elixir, Haskell, Scala, R, Lua, Perl, C, C++, Objective-C, and others. The scanner identifies import, require, use, include, and equivalent statements specific to each language.
The full list is in the User Guide, Appendix D: Supported Languages for Import Scanning.
There are several common reasons:
For the most accurate results, commit your lockfiles to the repository. See the User Guide, Section 14: Repository Management.
SBOMs can be updated in two ways:
After SBOM sync, license scanning and IP proof generation are triggered automatically. See the User Guide, Section 14: Repository Management.
An SBOM becomes stale when the connected repository receives new changes after the last sync. This is detected through webhook push events (for GitHub, Codeberg, and Forgejo with configured webhooks) or during the nightly auto-sync check. The Repos page and product detail page display an Update Available indicator next to stale SBOMs, and you can choose to sync immediately or wait for the nightly run.
See the User Guide, Section 14: Repository Management.
Yes. CRANIS2 supports exporting SBOMs in two industry-standard formats:
Exports are available from the product detail page and are also included in the Due Diligence export package. See the User Guide, Appendix E: SBOM Export Formats.
CRANIS2 evaluates every dependency in a product's SBOM against a local vulnerability database. The database is built from two authoritative sources -- OSV (covering 263,000+ advisories) and NVD (covering 182,000+ CVEs). The local database deduplicates across both sources and uses CPE matching combined with ecosystem-specific filtering to minimise false positives. When a match is found, a finding is created with the vulnerability details, severity, affected package, and fix version (if available).
See the User Guide, Section 17: Risk Findings.
CRANIS2 uses two complementary sources:
Both databases are synchronised nightly at 1 AM UTC. See the User Guide, Section 17: Risk Findings.
The platform scheduler runs a comprehensive vulnerability scan across all products at 3 AM UTC daily. You can also trigger a scan manually from the product detail page at any time. Since the vulnerability database is synchronised at 1 AM UTC, the 3 AM scan always runs against the latest available data. Scans deduplicate findings to avoid alerting on the same vulnerability multiple times.
See the User Guide, Section 17: Risk Findings and Section 25: Automated Background Processes.
Findings use four severity levels derived from CVSS (Common Vulnerability Scoring System) scores:
| Severity | CVSS Range | Platform Colour |
|---|---|---|
| Critical | 9.0 -- 10.0 | Red |
| High | 7.0 -- 8.9 | Red |
| Medium | 4.0 -- 6.9 | Amber |
| Low | 0.1 -- 3.9 | Green |
See the User Guide, Section 17: Risk Findings.
Navigate to the finding on the Risk Findings page or the product detail page. Each finding can be set to one of five statuses using inline editing. You can change the status directly from the table row. For Mitigated findings, a notes text area is available to document the workaround. For Dismissed findings, a reason field captures the justification. All status changes are recorded in the audit trail.
See the User Guide, Section 17: Risk Findings.
| Status | Meaning | When to Use |
|---|---|---|
| Open | New finding, not yet reviewed | Automatically assigned on creation |
| Acknowledged | Team is aware and evaluating | Reviewed but no action decided yet |
| Mitigated | Workaround or partial fix applied | Temporary measure in place |
| Resolved | Fully fixed | Vulnerable dependency updated or removed |
| Dismissed | Not applicable or accepted risk | Vulnerable code path not reachable, or risk accepted |
See the User Guide, Section 17: Risk Findings.
Yes. If a vulnerability finding represents an actively exploited vulnerability, you can create an ENISA report directly from the Risk Findings page. The report creation form will be pre-populated with data from the finding -- affected dependency, severity, CVSS score, and description -- saving you time during a time-sensitive reporting process.
See the User Guide, Section 17: Risk Findings and Section 10: ENISA Reporting.
You must file an ENISA report when you become aware of either:
If in doubt, err on the side of filing. Late reporting carries regulatory consequences; over-reporting does not. These obligations become legally binding in September 2026. See the User Guide, Section 10: ENISA Reporting.
Navigate to the Vulnerability Reports page and click New Report. The creation form collects three required fields: the affected product (selected from your portfolio), the report type (Actively Exploited Vulnerability or Severe Incident), and the awareness date and time (which starts the deadline clock). After creation, you can set the CSIRT country, affected member states, TLP classification, and ENISA reference number.
See the User Guide, Section 10: ENISA Reporting.
Once a report is created with an awareness date, CRANIS2 automatically calculates three deadlines:
The report detail page shows the timeline visually with submitted stages marked as complete and upcoming deadlines displayed as countdowns. See the User Guide, Section 10: ENISA Reporting.
The Early Warning is the first mandatory stage, due within 24 hours of becoming aware of the issue. It should include a summary of the vulnerability or incident, an initial assessment of scope, and whether malicious action is suspected. CRANIS2 provides a structured form with fields appropriate to this stage. Intermediate updates can be submitted between the Early Warning and the Notification stage for progress reporting.
See the User Guide, Section 10: ENISA Reporting.
A vulnerability report is filed when you discover an actively exploited vulnerability in your product. An incident report is filed when a severe security incident has significant impact on product security. The key practical difference is the Final Report deadline: 14 days for vulnerability reports and 1 month for incident reports. The Early Warning (24 hours) and Notification (72 hours) deadlines are the same for both types.
See the User Guide, Section 10: ENISA Reporting.
Yes. CRANIS2 supports post-close addenda. You can submit additional intermediate stages even after a report has been closed, in case new information emerges or your understanding of the issue evolves. This means you do not need to create a new report if you discover additional details after closure.
See the User Guide, Section 10: ENISA Reporting.
CRANIS2 classifies every dependency's license into three categories: Permissive (MIT, Apache-2.0, BSD, ISC), Copyleft (GPL, LGPL, AGPL, MPL, SSPL), and Unknown/NOASSERTION (no declared license). A rules engine then evaluates each license against your product's distribution model to produce a compatibility verdict: Compatible, Incompatible, or Review Needed. The engine also detects 14 known cross-license incompatibilities where two licenses in the same dependency tree conflict.
See the User Guide, Section 11: License Compliance.
Permissive licenses (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Unlicense) allow unrestricted use, including in proprietary products, with minimal obligations (typically just attribution). Copyleft licenses (GPL-2.0, GPL-3.0, LGPL, AGPL-3.0, MPL-2.0, SSPL-1.0) require derivative works to be distributed under the same or compatible terms. The practical impact of copyleft depends on your distribution model and how the dependency is linked.
See the User Guide, Section 11: License Compliance.
NOASSERTION means the dependency has no declared license or uses a license identifier that CRANIS2 does not recognise. Dependencies with NOASSERTION require manual review because the absence of a declared license may carry legal risk -- you could be using code with no legal permission to do so. Investigate the dependency's actual licensing terms on its project page before distributing your product.
See the User Guide, Section 11: License Compliance.
The compatibility engine evaluates every dependency's license against your product's distribution model and produces one of three verdicts: Compatible (safe to use), Incompatible (action required), or Review Needed (ambiguous, manual review recommended). The engine also detects 14 known cross-license incompatibilities based on FSF guidance, where two licenses in the same dependency tree conflict with each other regardless of your distribution model.
See the User Guide, Section 11: License Compliance.
Your distribution model has a direct and significant impact:
See the User Guide, Section 11: License Compliance.
Yes. If a license finding does not apply to your situation (for example, a test-only dependency not included in the distributed product, or a build tool not bundled with the output), you can waive the finding and record your reasoning. Waived findings are retained in the audit trail for accountability but are excluded from active compliance counts and dashboards.
See the User Guide, Section 11: License Compliance.
IP Proof is CRANIS2's implementation of cryptographic timestamping for compliance evidence. It creates independently verifiable proof that a specific set of data -- your product's software composition -- existed at a specific point in time. This is valuable for establishing prior art against patent claims, demonstrating compliance as of a particular date for auditors, and verifying the integrity of escrow deposits.
See the User Guide, Section 12: IP Proof.
RFC 3161 defines a protocol for trusted timestamping. CRANIS2 generates a SHA-256 hash of your product's composition data, sends this hash to a Time Stamping Authority (FreeTSA.org), and receives back a signed timestamp token. The TSA signs the hash together with the current time, creating proof that the data existed at that moment. Critically, the TSA never sees your source code or dependency data -- only the cryptographic hash. The resulting timestamp is recognised under the EU eIDAS Regulation (910/2014) as legally admissible evidence.
See the User Guide, Section 12: IP Proof.
Snapshots are created automatically after every SBOM sync. The nightly auto-sync at 2 AM UTC triggers a license scan, and the license scan triggers IP proof creation. This means your IP proof stays current without any manual action. Each snapshot records the SHA-256 content hash, verification status, and creation date. You can view all snapshots on the IP Proof page.
See the User Guide, Section 12: IP Proof.
A verified snapshot means the RFC 3161 timestamp token has been successfully validated, confirming that the content hash was signed by the Time Stamping Authority at the recorded date and time. This verification can be performed independently by anyone with the timestamp token, providing legally admissible proof under EU eIDAS that your software composition existed as of that specific date.
See the User Guide, Section 12: IP Proof.
The Due Diligence export generates a comprehensive, investor-ready compliance package for any of your products. It is designed for scenarios where you need to demonstrate your compliance posture to a third party: during fundraising, acquisition due diligence, customer procurement, regulatory inspection, internal audit, or cyber insurance applications. You can preview the contents before downloading.
See the User Guide, Section 13: Due Diligence Export.
The ZIP file contains five items:
| File | Format | Contents |
|---|---|---|
| Due Diligence Report | Executive summary of compliance posture | |
| Software Bill of Materials | CycloneDX 1.6 JSON | Complete dependency inventory |
| License Findings | CSV | All dependencies with compliance verdicts |
| Vulnerability Summary | JSON | All findings with severities and CVEs |
| Full License Texts | Text files | Complete text for each non-permissive license |
See the User Guide, Section 13: Due Diligence Export.
Yes. You select a specific product from the dropdown before generating the export. Each ZIP covers a single product and includes all compliance data associated with it. A preview is shown before you download, including summary statistics, non-permissive dependencies, and CRA obligation status. If you need exports for multiple products, generate one for each product separately.
See the User Guide, Section 13: Due Diligence Export.
Source code escrow is a business continuity mechanism where a copy of your product's source code is deposited with a trusted third party, with agreed conditions under which it may be released to designated beneficiaries. If your company ceases to operate, your customers are not left without access to the software they depend on. For B2B software vendors, escrow is increasingly a procurement requirement and provides a tangible trust signal during sales conversations.
See the User Guide, Section 7: Escrow.
CRANIS2 uses a self-hosted Forgejo instance (a lightweight, open-source Git forge) for escrow deposits. Escrow is opt-in and configured per product. When enabled, your repository is mirrored to the Forgejo instance. You can also configure which artifact types to include alongside the source code: SBOM, vulnerability reports, license audit, IP proof, CRA documentation, and compliance timeline. You choose a release model (open source or designated recipients) to control what happens if the deposit needs to be released.
See the User Guide, Section 7: Escrow.
The Forgejo instance is hosted in Switzerland, ensuring European data sovereignty. It runs within the CRANIS2 infrastructure and is separate from your production repository -- it functions purely as a deposit. The escrow data never leaves European jurisdiction.
See the User Guide, Section 7: Escrow.
Automated escrow deposits run daily at 5 AM UTC for all products with escrow enabled. Each deposit mirrors the current state of your repository and any configured compliance artifacts. This ensures the escrow is always current without requiring manual action.
See the User Guide, Section 7: Escrow and Section 25: Automated Background Processes.
When you delete a product from CRANIS2, the Forgejo escrow repository is not deleted. It is preserved under legal retention policy, ensuring continuity of any escrow agreements regardless of the product's status in CRANIS2. The data exit ZIP you receive on product deletion includes references to the preserved escrow repository.
See the User Guide, Section 7: Escrow and Section 5: Products.
A Technical File in CRANIS2 corresponds to the CRA Annex VII requirements. It is a structured documentation package with eight sections, each addressing a specific regulatory requirement. Every section provides a content editor for substantive documentation, a notes field for internal annotations (not included in exports), and a status indicator (Not Started, In Progress, or Complete). The cross-product Technical Files dashboard shows completion progress for all products at a glance.
See the User Guide, Section 9: Technical Files.
Navigate to the product detail page and open the Technical File tab. Click on any of the eight sections to open its editor. Write your documentation in the content field, add internal notes if needed, and set the status. The CRA reference for each section is displayed alongside the editor so you can see exactly which regulatory requirement you are addressing. Content is saved when you submit the form.
See the User Guide, Section 9: Technical Files.
Within the Technical File tab, the Annex I Part I checklist covers 13 essential cybersecurity requirements labelled (a) through (m). These include security by design, no known vulnerabilities at market placement, secure defaults, access protection, data confidentiality, data integrity, data minimisation, availability protection, minimal network impact, incident resilience, security logging, secure data removal, and security update mechanisms. For each requirement, you can mark it as applicable or not applicable and provide evidence of how it is met.
See the User Guide, Section 9: Technical Files and Section 2: Regulatory Context.
CRA obligations are specific requirements derived from CRA articles and mapped to each product based on its CRA category. They cover product security (Annex I), vulnerability handling (Article 13), security updates, SBOM maintenance, technical documentation (Annex VII), conformity assessment (Articles 24--28), CE marking (Article 22), authority reporting (Article 14), and market surveillance cooperation (Article 43). Each obligation has one of three statuses: Not Started, In Progress, or Met. Statuses can be changed inline from the obligations table.
See the User Guide, Section 8: Obligations Tracking.
CRANIS2 offers two plans:
An active contributor is anyone who has made at least one contribution to a connected repository. Bot accounts are automatically identified and excluded from billing. The Billing page shows a contributor roster with badges indicating each contributor's status: active (green), bot (grey), departed (red), and inactive (amber). You can upgrade or downgrade between plans at any time from the Billing page; Stripe handles proration automatically.
See the User Guide, Section 18: Billing.
The trial follows a defined lifecycle:
You can subscribe at any point to restore full access. See the User Guide, Section 18: Billing.
The billing gate is a global middleware that activates when an organisation enters read-only, suspended, or cancelled status. It intercepts all write operations -- creating products, updating obligations, filing reports, syncing SBOMs, editing technical files -- and returns a billing error. You can still view all your data, read reports, export SBOMs and due diligence packages, and access the billing page to resolve the payment issue.
See the User Guide, Section 18: Billing.
In read-only mode you retain full read access: viewing all products, findings, reports, and compliance data; exporting SBOMs in CycloneDX and SPDX formats; downloading due diligence packages; viewing the audit log; and accessing the billing page to subscribe or resolve payment issues. All write operations (create, update, delete) are blocked until your billing status is restored.
See the User Guide, Section 18: Billing.
Navigate to the Billing page under the Billing section in the sidebar. Click the subscribe button to be directed to Stripe's hosted checkout, where you enter your payment details. You can also set your billing email, company name, and VAT number on the Billing page. Once payment is processed, your account status moves to Active and all features remain available.
See the User Guide, Section 18: Billing.
The Billing page provides a link to Stripe's customer portal, where you can view invoices, update your payment method, and cancel your subscription. If a payment fails, you receive a 7-day grace period with full access before the account enters read-only mode. Resolving the payment failure during the grace period prevents any disruption.
See the User Guide, Section 18: Billing.
The Trust Centre is a public-facing directory of organisations using CRANIS2 to demonstrate their compliance posture. It is accessible without login, allowing prospective customers, partners, procurement teams, and auditors to browse listed companies and assess their compliance readiness at a glance through compliance badges.
See the User Guide, Section 19: Trust Centre.
Navigate to the Trust Centre settings page. From there you can toggle your listing visibility on or off, write a tagline and longer description, select product categories that apply to your organisation (from 10 available categories), and choose which of your products to feature on the listing. Listings are auto-approved by default. Platform administrators can revoke approval if necessary. Trust Centre settings require a Pro plan subscription.
See the User Guide, Section 19: Trust Centre.
Each listing displays live compliance badges summarising the organisation's posture: CRA status, percentage of obligations met, technical file completion percentage, product count, open vulnerability count, and licence compliance percentage. These badges are calculated from live data and update automatically as the organisation's compliance posture evolves.
See the User Guide, Section 19: Trust Centre.
Yes, if you are logged in. A contact modal allows you to send a message to listed organisations. Rate limits are enforced to prevent abuse: a maximum of 3 messages per day per user across all organisations, and 1 message per organisation per 7-day period.
See the User Guide, Section 19: Trust Centre.
Listings are auto-approved by default. When you toggle your listing to visible and save your profile, it appears in the public directory immediately. Platform administrators can revoke approval if necessary. You can toggle your listing off at any time to remove it from public view. Trust Centre settings require a Pro plan subscription.
See the User Guide, Section 19: Trust Centre.
Yes. Navigate to your Account page and select "Export My Data." The platform generates a structured JSON export of all your personal data, including account details, organisation, products, findings, and usage history. OAuth tokens and password hashes are excluded for security.
Navigate to your Account page and select "Delete My Account." You will need to confirm your password. If you are the sole administrator of an organisation, you must first transfer admin rights. Your personal data is immediately deleted; billing records and audit trail entries are anonymised for legal retention.
Telemetry events are retained for 90 days, feedback for 2 years, and Copilot response cache for 24 hours. Compliance data (products, obligations, technical files) is retained for the duration of your subscription. After account deletion, anonymised billing and audit records are retained for legal obligations.
CRANIS2 partners with affiliates who refer new customers to the platform. Affiliates earn commissions on referred subscriptions and can manage their activity through a self-service dashboard.
Enter your bonus code on the signup page. Valid bonus codes typically extend your free trial from 30 to 90 days.
Affiliate accounts are created by platform administrators. If you are interested in becoming an affiliate, contact the CRANIS2 team.
Yes. Open-source projects that meet eligibility criteria (OSI-approved licence, active repository) are automatically classified for free access through the platform's trust scoring system.
Yes. Non-profit organisations can apply for free access by submitting verification documentation. Applications are reviewed by platform administrators.
CRANIS2 generates notifications for the following events:
Notifications have five severity levels: critical, high, medium, low, and info. See the User Guide, Section 4: Navigating the Platform.
Yes. The Notifications page supports filtering by severity level and notification type. You can also mark individual notifications as read. A badge on the sidebar shows the count of unread notifications so you can quickly assess whether new alerts require attention without navigating to the page.
See the User Guide, Section 4: Navigating the Platform.
Yes. The Audit Log page under Settings records significant actions taken within your organisation, providing a traceable record of who did what and when. This is valuable for internal governance reviews, regulatory inspections, demonstrating continuous compliance to auditors, and investigating any unexpected changes to your compliance data.
See the User Guide, Section 22: Audit Log.
This almost certainly means the billing gate is active. Your organisation may have entered read-only mode due to an expired trial (after the 7-day grace period), a failed payment, or account suspension. Navigate to the Billing page to check your current billing status and take the appropriate action -- either subscribing for the first time or resolving a payment failure.
See the User Guide, Section 18: Billing.
Work through this checklist:
See the User Guide, Section 14: Repository Management.
Not necessarily. A scan with no results means no known vulnerabilities were found in the current SBOM against the databases available at scan time. New vulnerabilities are published daily, and the databases are synchronised nightly at 1 AM UTC, so future scans may discover issues. Also confirm that your SBOM is not empty -- a scan against an empty SBOM will naturally return zero findings. Finally, remember that vulnerability databases may not cover all ecosystems equally.
See the User Guide, Section 17: Risk Findings.
This is a display formatting issue that can occur when date values from the database are not in the expected format. If you encounter this, try refreshing the page first. If the issue persists, submit a bug report using the Feedback button at the bottom of the sidebar -- select the "bug" category and the page URL will be captured automatically. This helps the development team identify and resolve the formatting issue.
See the User Guide, Section 23: Feedback System.
The badge and the notifications page may briefly show different counts if new notifications arrive between page loads or if there is a caching delay. Refreshing the page should synchronise the count. If the discrepancy persists after a refresh, submit a bug report using the Feedback button at the bottom of the sidebar.
See the User Guide, Section 4: Navigating the Platform.
Platform Administration is a separate role from organisation admin. Organisation admins manage their own company's account, products, and team members. Platform admins manage the entire CRANIS2 platform, including all organisations, system health, vulnerability database administration, and test results. Platform admin access is granted at the system level and is not available to regular organisation admins, regardless of their admin status within their own organisation.
See the User Guide, Section 24: Platform Administration.
For detailed guidance on any topic covered in this FAQ, refer to the CRANIS2 User Guide.