# Pictor Consulting AB > Pictor Consulting AB is a Swedish engineering consultancy providing senior system safety leadership, embedded product security and Cyber Resilience Act readiness for manufacturers of safety-critical and connected products. Site: https://pictorab.com/ Contact: info@pictorab.com Language: English Last reviewed: 2026-08-19 ## About this file This file is published for AI search engines and agents. Content on this site may be quoted and cited with attribution to Pictor Consulting AB and a link to the source page. Regulatory statements describe EU law as published; they are not legal advice for a specific product. ## What Pictor does - System safety engineering - Functional safety - Product cybersecurity - Cyber Resilience Act compliance - Embedded systems engineering - Safety cases and technical documentation ## Services - [System safety engineering](https://pictorab.com/system-safety): Hazard-driven engineering from first architecture to accepted evidence. - [CRA consulting](https://pictorab.com/cra-consulting): Scope, gap assessment, lifecycle processes and technical documentation. - [Engineering expertise](https://pictorab.com/expertise): Embedded systems, safety-critical architecture and product security. ## Tools - [CRA scope checker](https://pictorab.com/cra-readiness-check): Check whether the Cyber Resilience Act applies to your product. ## Guides - [Guides](https://pictorab.com/guides): In-depth guides to the CRA, functional safety and product security. - [What the Cyber Resilience Act requires of manufacturers](https://pictorab.com/guides/cra-requirements): A working reference to the core obligations the Cyber Resilience Act places on manufacturers of products with digital elements, and how they interact. - [CRA timeline and deadlines](https://pictorab.com/guides/cra-timeline): The confirmed dates in the Cyber Resilience Act's phase-in, from entry into force through reporting duties to full application, and what to prepare against each. - [Conformity assessment routes under the CRA](https://pictorab.com/guides/cra-conformity-assessment): How the CRA's conformity assessment procedures differ for default, important and critical products, and how to choose and prepare for the right route. - [CRA technical documentation](https://pictorab.com/guides/cra-technical-documentation): What the Cyber Resilience Act requires in a technical documentation file, how to structure it, and the evidence gaps that cause assessment delays. - [SBOM and coordinated vulnerability handling](https://pictorab.com/guides/sbom-and-vulnerability-handling): How a software bill of materials supports vulnerability handling and CRA reporting duties, and what a working process looks like in practice. - [ISO 26262 functional safety](https://pictorab.com/guides/iso-26262-functional-safety): An engineering-level overview of ISO 26262: scope, ASIL classification, the V-model lifecycle, and the evidence a safety case needs to hold together. - [IEC 61508 functional safety basics](https://pictorab.com/guides/iec-61508-functional-safety): The generic functional safety standard behind sector-specific derivatives: SIL classification, the safety lifecycle, and how it is applied in practice. - [IEC 62443 product security](https://pictorab.com/guides/iec-62443-product-security): How IEC 62443 structures security for industrial automation and control systems, its security levels, and what product certification evidence involves. - [ISO/SAE 21434 automotive cybersecurity](https://pictorab.com/guides/iso-21434-automotive-cybersecurity): How ISO/SAE 21434 structures cybersecurity engineering for road vehicles, its risk assessment method, and how it relates to functional safety work. - [Safety cases and evidence chains](https://pictorab.com/guides/safety-case-and-evidence): What a safety case is, the evidence a reviewer expects, and why traceability from hazard to verification is the discipline that determines credibility. ## Answers - [Answers](https://pictorab.com/answers): Direct answers to the questions engineering teams ask most. - [Does the Cyber Resilience Act apply to my product?](https://pictorab.com/answers/does-cra-apply-to-my-product): The CRA applies to any product with digital elements placed on the EU market that has a direct or indirect logical or physical connection to a device or network, whether hardware or software. A small number of categories are excluded because they are already covered by equivalent sector-specific rules, such as certain medical devices, vehicles and aviation equipment. - [When does the Cyber Resilience Act apply?](https://pictorab.com/answers/when-does-cra-apply): The CRA entered into force on 10 December 2024. Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. The remaining obligations, including essential requirements, conformity assessment and CE marking specific to the CRA, apply from 11 December 2027. - [Are products already on the market affected by the CRA?](https://pictorab.com/answers/cra-existing-products-on-market): Products lawfully placed on the market before the relevant obligations apply are generally not required to be redesigned retroactively. However, a substantial modification after the obligations take effect can bring a product back into scope, and ongoing obligations such as vulnerability handling apply based on current supply and support rather than the original placing-on-market date. - [What counts as a substantial modification under the CRA?](https://pictorab.com/answers/cra-substantial-modification): A substantial modification is a change to a product with digital elements that affects its compliance with the essential cybersecurity requirements or changes its intended use, for example a significant software update that alters functionality or connectivity. A substantial modification after the CRA's obligations apply can bring a previously exempt product back into scope, requiring a fresh conformity assessment. - [What are important and critical products under the CRA?](https://pictorab.com/answers/cra-important-critical-products): The CRA introduces two categories of higher-risk products with digital elements, listed in its annexes: important and critical. Important products include categories such as operating systems, firewalls and password managers; critical products include hardware security modules and other components where a failure could have a wide security impact. Both categories attract stricter conformity assessment routes than default products. - [What conformity assessment routes exist under the CRA?](https://pictorab.com/answers/cra-conformity-assessment-routes): The CRA sets out different conformity assessment routes depending on a product's classification. Default products generally allow manufacturer self-assessment against the essential requirements. Important products typically require either a documented self-assessment against harmonised standards or third-party involvement, while critical products require third-party conformity assessment by a notified body. - [Is CE marking under the CRA a new marking scheme?](https://pictorab.com/answers/cra-ce-marking): No. The CRA uses the existing CE marking framework rather than introducing a separate mark. It adds cybersecurity as a further requirement that a product with digital elements must satisfy, alongside any other applicable EU legislation, before the CE mark can be affixed and the product placed on the EU market. - [What technical documentation does the CRA require?](https://pictorab.com/answers/cra-technical-documentation-requirements): The CRA requires technical documentation that demonstrates conformity with the essential cybersecurity requirements, including a description of the product's design and development, the cybersecurity risk assessment, verification and test results, and the software bill of materials. This documentation must be retained for a defined period after the product is placed on the market. - [What is a software bill of materials (SBOM)?](https://pictorab.com/answers/what-is-an-sbom): A software bill of materials is a structured, machine-readable inventory of the components, libraries and dependencies used to build a software product, typically including component names, versions and supplier information. Under the CRA, manufacturers must produce an SBOM for products with digital elements in a commonly used format, covering at least top-level dependencies. - [Should an SBOM be generated manually or by the build pipeline?](https://pictorab.com/answers/sbom-generation-pipeline): An SBOM should be generated automatically as part of the build pipeline rather than compiled manually at the end of a project. Automated generation keeps the inventory accurate as dependencies change, supports the CRA's requirement for up-to-date documentation, and provides the queryable component data needed to respond quickly when a vulnerability is disclosed in a shared dependency. - [What must a CRA vulnerability handling process include?](https://pictorab.com/answers/cra-vulnerability-handling-process): A CRA-compliant vulnerability handling process must include a published point of contact for reporting, a coordinated disclosure procedure, an internal triage capability to assess severity and exploitation status, and a mechanism to deliver free security updates for the product's defined support period. Reviewers expect evidence that the process is operating, not only documented. - [What are the CRA's vulnerability reporting timelines?](https://pictorab.com/answers/cra-vulnerability-reporting-timelines): From 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents to the relevant authority — typically ENISA and the national CSIRT — within a 24-hour early warning, followed by a fuller notification within 72 hours, and a final report once the issue is resolved. Meeting these windows depends on an accurate component inventory and a rehearsed decision chain. - [What counts as a severe incident under the CRA?](https://pictorab.com/answers/cra-severe-incident-definition): The CRA does not set a single numeric threshold for a severe incident. It is generally understood as an incident with a significant negative impact on the availability, confidentiality or integrity of a product with digital elements, or on the services it supports. Manufacturers need documented, consistent triage criteria to make this judgement quickly enough to meet reporting deadlines. - [Does the CRA apply to open-source software?](https://pictorab.com/answers/does-cra-apply-to-open-source): Open-source software developed and supplied outside a commercial activity is generally outside the CRA's scope. Once open-source components are integrated into a commercial product, responsibility shifts to the manufacturer of that product, who must cover those components in the SBOM and risk assessment. The CRA introduces a lighter set of obligations for open-source stewards of widely used projects. - [What obligations does the CRA place on open-source stewards?](https://pictorab.com/answers/open-source-steward-obligations): The CRA defines a narrower category of obligations for open-source software stewards, such as foundations that coordinate widely used projects on a non-commercial basis. These focus on cybersecurity policy, vulnerability handling coordination and cooperation with authorities, and are proportionate to a non-commercial role rather than mirroring full manufacturer obligations. - [Who is responsible for CRA compliance in a supply chain?](https://pictorab.com/answers/cra-supply-chain-responsibility): The manufacturer of the finished product with digital elements carries the primary CRA obligations, including risk assessment, conformity assessment and vulnerability handling. Component suppliers have narrower duties, mainly providing information the manufacturer needs for its own risk assessment and SBOM. Importers and distributors have separate, lighter duties to verify conformity markings and documentation before placing or making a product available. - [What are an importer's obligations under the CRA?](https://pictorab.com/answers/cra-importer-obligations): Under the CRA, an importer must verify that a manufacturer outside the EU has carried out the appropriate conformity assessment, that CE marking and required documentation are present, and that a point of contact for cybersecurity issues exists. Importers must also ensure storage and transport conditions do not compromise conformity, and must inform the manufacturer or authorities if they identify non-conformity. - [What are a distributor's obligations under the CRA?](https://pictorab.com/answers/cra-distributor-obligations): A distributor's CRA obligations are lighter than a manufacturer's or importer's: before making a product available on the market, a distributor must verify that CE marking, the EU declaration of conformity and required accompanying information are present, and must not make available a product it knows or suspects to be non-conformant. Distributors must also cooperate with market surveillance authorities. - [What are the penalties for CRA non-compliance?](https://pictorab.com/answers/cra-penalties): The CRA allows national market surveillance authorities to impose administrative fines for non-compliance, with the regulation setting maximum fine levels similar in scale to other EU digital and product legislation, calculated as a percentage of global annual turnover or a fixed amount, whichever is higher. Authorities can also require corrective action, restrict market availability or order a product's withdrawal or recall. - [What do market surveillance authorities check under the CRA?](https://pictorab.com/answers/cra-market-surveillance): Market surveillance authorities check that technical documentation shows a coherent chain from identified risks to design decisions to verification evidence, and that CE marking and declarations of conformity are correctly in place. They also expect to see evidence that the vulnerability handling process is actually operating, such as intake records and update history, rather than only a written policy. - [What is the CRA's support period?](https://pictorab.com/answers/cra-support-period-meaning): The support period is the length of time, defined by the manufacturer and reflecting the product's expected use, during which security updates must be provided free of charge. It must be documented and communicated to users, and the mechanism for delivering updates to deployed units must be planned and demonstrably capable of reaching the installed base, not merely stated as a policy. - [What is IEC 62443?](https://pictorab.com/answers/what-is-iec-62443): IEC 62443 is a series of international standards addressing the cybersecurity of industrial automation and control systems, covering security requirements for asset owners, integrators, product suppliers and the products themselves. It defines security levels, zones and conduits for network segmentation, and secure development lifecycle requirements for products, notably in IEC 62443-4-1. - [What are IEC 62443 security levels?](https://pictorab.com/answers/iec-62443-security-levels): IEC 62443 defines security levels from SL 0 to SL 4, describing the capability of a system or component to resist attacks of increasing sophistication and resources, from no protection at SL 0 through to protection against attacks by resourceful, highly motivated adversaries with extended resources at SL 4. Levels are assigned per zone or component based on a documented risk assessment, not applied uniformly across a system. - [How does IEC 62443 relate to CRA compliance?](https://pictorab.com/answers/cra-and-iec-62443-relationship): IEC 62443 is not itself a CRA harmonised standard, but its secure development lifecycle and product security requirements map closely onto several CRA essential requirements, particularly around secure design, vulnerability handling and secure default configuration. Manufacturers already following IEC 62443-4-1 and 4-2 typically have a head start on demonstrating CRA conformity, though a direct evidence mapping is still needed. - [What is ISO/SAE 21434?](https://pictorab.com/answers/what-is-iso-21434): ISO/SAE 21434 is the international standard for cybersecurity engineering in road vehicles, defining a risk-based approach across the vehicle lifecycle from concept through development, production, operation and decommissioning. It requires a threat analysis and risk assessment (TARA), cybersecurity goals and requirements traceable to those goals, and verification evidence, mirroring the structure of functional safety standards such as ISO 26262. - [What is a threat analysis and risk assessment (TARA)?](https://pictorab.com/answers/what-is-tara): A threat analysis and risk assessment is a structured method, required by ISO/SAE 21434, for identifying assets, threat scenarios and attack paths for a system, and assessing the resulting risk in terms of impact and attack feasibility. The output determines cybersecurity goals and requirements, which must then be traced through design, implementation and verification. - [How do ISO 26262 and ISO/SAE 21434 relate to each other?](https://pictorab.com/answers/iso-26262-and-iso-21434-relationship): ISO 26262 addresses functional safety in road vehicles, focused on risks arising from malfunctioning behaviour, while ISO/SAE 21434 addresses cybersecurity, focused on risks arising from malicious attack. The two standards share a similar lifecycle structure and both rely on hazard or threat analysis followed by traceable requirements and verification, and vehicle programmes typically run safety and security analyses in a coordinated way because a security compromise can create a safety hazard. - [What is the purpose of threat modelling?](https://pictorab.com/answers/threat-modelling-purpose): Threat modelling is a structured exercise, carried out early and revisited through a product's development, to identify how a system could be attacked, which assets and interfaces are exposed, and which mitigations are proportionate. Its purpose is to shift security decisions to the design stage, where they are cheaper to make, rather than discovering weaknesses through testing or after deployment. - [What is a secure development lifecycle (SDL)?](https://pictorab.com/answers/secure-development-lifecycle-meaning): A secure development lifecycle is a set of security activities integrated into each phase of software or product development, from requirements and design through implementation, verification and release, rather than security testing bolted on at the end. Typical activities include threat modelling, secure coding standards, static and dynamic analysis, and a vulnerability handling process that continues after release. - [What is ISO 26262?](https://pictorab.com/answers/what-is-iso-26262): ISO 26262 is the international standard for functional safety of electrical and electronic systems in road vehicles, defining a lifecycle from concept and hazard analysis through system, hardware and software development to production and operation. It introduces Automotive Safety Integrity Levels (ASIL) to grade risk and scale the rigour of development and verification activities accordingly. - [What is an ASIL rating?](https://pictorab.com/answers/what-is-asil): An Automotive Safety Integrity Level (ASIL) is a risk classification defined by ISO 26262, ranging from ASIL A (lowest) to ASIL D (highest), plus QM for hazards not requiring safety measures. It is derived from an assessment of severity, exposure and controllability for a given hazardous event, and determines the rigour required for the associated development and verification activities. - [What is the difference between SIL and ASIL?](https://pictorab.com/answers/sil-vs-asil): Safety Integrity Level (SIL), defined by IEC 61508, and Automotive Safety Integrity Level (ASIL), defined by ISO 26262, are both risk-based classification schemes that scale the rigour of safety engineering to the severity of potential harm. SIL is used across general industrial functional safety applications, while ASIL is specific to road vehicles and is derived using a different risk parameter set tailored to automotive scenarios. - [What is IEC 61508?](https://pictorab.com/answers/what-is-iec-61508): IEC 61508 is the base international standard for the functional safety of electrical, electronic and programmable electronic safety-related systems, applicable across industries and forming the basis for several sector-specific derivatives such as ISO 26262 for road vehicles and IEC 61511 for process industries. It defines a safety lifecycle, Safety Integrity Levels (SIL) and requirements for hardware and software development. - [What is a hazard analysis and risk assessment?](https://pictorab.com/answers/hazard-analysis-and-risk-assessment): A hazard analysis and risk assessment (HARA) is a structured method for identifying hazardous events a system could cause, and for estimating the associated risk using parameters such as severity, exposure and controllability. Its output is a set of safety goals and an assigned integrity level, such as ASIL or SIL, which then drives the scope and rigour of subsequent design and verification work. - [What is the purpose of a safety case?](https://pictorab.com/answers/safety-case-purpose): A safety case is a structured argument, supported by evidence, that a system is acceptably safe for a specific application and operating context. Its purpose is to make the reasoning behind a safety claim explicit and reviewable, linking hazards, mitigations, design decisions and verification results into a coherent chain rather than leaving safety confidence implicit in scattered documents. - [What evidence supports a safety case?](https://pictorab.com/answers/safety-case-evidence-types): A safety case is typically supported by hazard analysis records, derived safety requirements, design rationale showing how each requirement is met, verification and test results, and records of any residual risk acceptance. Evidence should be traceable end to end, so a reviewer can follow the argument from an identified hazard to the specific mitigation and the proof that it works as intended. - [How do safety and security interact in system design?](https://pictorab.com/answers/safety-security-interaction): Safety and security analyses address different causes — unintended malfunction versus deliberate attack — but their consequences can converge, since a successful cyber attack can create a safety hazard in a connected system. Programmes that run safety and security assessments in isolation risk missing these interactions, so coordinated hazard and threat analysis, and shared traceability between safety and security requirements, is increasingly treated as necessary practice. - [Why is requirements traceability important?](https://pictorab.com/answers/requirements-traceability-purpose): Requirements traceability links each requirement to its origin, such as a hazard or stakeholder need, and forward to its design, implementation and verification evidence. It matters because it lets a reviewer confirm that every requirement has been addressed and tested, and that every design decision and test exists for a reason, which is essential evidence in safety cases, security conformity assessments and audits. - [What is the difference between verification and validation?](https://pictorab.com/answers/verification-vs-validation): Verification confirms that a system meets its specified requirements, typically answering 'did we build it right', while validation confirms that the system meets the actual needs of its intended use in its operating context, answering 'did we build the right thing'. Both are needed because a system can satisfy every written requirement and still fail to be fit for purpose if the requirements themselves were incomplete or wrong. - [Why does conformity to a recognised standard matter if it is not legally required?](https://pictorab.com/answers/why-standards-conformity-matters): Conformity to a recognised standard, even where not legally mandated, provides a shared reference for what 'sufficiently rigorous' means, which simplifies communication with customers, insurers, auditors and regulators. It also gives a project access to established methods and known pitfalls rather than reinventing a lifecycle from scratch, reducing the risk that a gap is only discovered after an incident. ## Comparisons - [Comparisons](https://pictorab.com/compare): How overlapping regulations and standards differ in practice. - [CRA vs NIS2: what is different, what overlaps](https://pictorab.com/compare/cra-vs-nis2): The CRA and NIS2 both address cybersecurity but regulate different subjects: products versus operators. A practical comparison for readiness planning. - [CRA vs the RED Delegated Regulation on cybersecurity](https://pictorab.com/compare/cra-vs-red-delegated-act): RED cybersecurity requirements and the CRA both apply to connected radio products. How the two regimes relate, and which one governs which product. - [CRA vs the Machinery Regulation](https://pictorab.com/compare/cra-vs-machinery-regulation): The Cyber Resilience Act and the new Machinery Regulation (EU) 2023/1230 both touch connected machinery. What each covers and how they interact. - [Safety engineering vs security engineering](https://pictorab.com/compare/safety-vs-security-engineering): Functional safety and cybersecurity engineering share methods but answer different questions. A practical comparison of scope, artefacts and decision authority. - [IEC 62443 vs ISO/SAE 21434](https://pictorab.com/compare/iec-62443-vs-iso-21434): Both standards address cybersecurity engineering but serve different sectors. A comparison of scope, process model and where each is expected as evidence. - [ISO 26262 vs IEC 61508](https://pictorab.com/compare/iso-26262-vs-iec-61508): ISO 26262 is the automotive-specific derivative of the generic functional safety standard IEC 61508. Scope, terminology and integrity level differences explained. - [In-house vs consultant safety leadership](https://pictorab.com/compare/in-house-vs-consultant-safety-leadership): Whether to build internal safety leadership or bring in external expertise depends on programme duration, assessor independence and available scale. - [Self-assessment vs Notified Body conformity assessment](https://pictorab.com/compare/self-assessment-vs-notified-body): The CRA conformity assessment route depends on product risk classification. When manufacturer self-assessment is permitted and when a Notified Body is required. ## Industries - [Industries](https://pictorab.com/industries): Sector regulatory pictures and typical engagements. - [Defence: system safety and cybersecurity readiness](https://pictorab.com/industries/defence): Defence programmes combine national safety and airworthiness standards with emerging cybersecurity obligations. What applies and what a typical engagement covers. - [Telecom: connected infrastructure and CRA/NIS2 overlap](https://pictorab.com/industries/telecom): Telecom operators and equipment vendors face NIS2 as operators and the CRA as manufacturers. What applies to network equipment, CPE and infrastructure. - [Automotive: functional safety, cybersecurity and type approval](https://pictorab.com/industries/automotive): Vehicle manufacturers and suppliers work under ISO 26262, ISO/SAE 21434 and UN R155/R156, with the CRA relevant mainly to non-vehicle connected products. - [Medical devices: MDR, IEC 62304 and CRA interaction](https://pictorab.com/industries/medical-devices): Medical devices are regulated under the MDR/IVDR and IEC 62304, and are generally excluded from the CRA where already covered by that dedicated regime. - [Industrial automation: IEC 62443, machinery safety and CRA](https://pictorab.com/industries/industrial-automation): Industrial control systems combine functional safety under IEC 61508, cybersecurity under IEC 62443, machinery safety and full CRA scope for most equipment. - [Energy: NIS2, critical infrastructure and connected equipment](https://pictorab.com/industries/energy): Energy operators face NIS2 as critical infrastructure operators while connected grid and metering equipment manufacturers face full CRA scope. - [Connected products and consumer IoT under the CRA](https://pictorab.com/industries/connected-products): Consumer and general-purpose connected products form the CRA's core, default-scope population. What manufacturers of IoT and smart devices need to plan for. ## Glossary - [Glossary](https://pictorab.com/glossary): Definitions for safety, security and CRA terminology. - [ASIL](https://pictorab.com/glossary/asil): ASIL is a risk classification defined in ISO 26262 that expresses the rigour of safety measures required for an automotive function, ranging from QM to ASIL D. - [CE marking](https://pictorab.com/glossary/ce-marking): CE marking is the manufacturer's declaration that a product complies with all applicable EU legislation, including the Cyber Resilience Act once its essential requirements apply. - [Conformity assessment](https://pictorab.com/glossary/conformity-assessment): Conformity assessment is the procedure by which a manufacturer demonstrates that a product meets applicable legal requirements before it is placed on the market. - [CVE](https://pictorab.com/glossary/cve): A CVE is a unique public identifier assigned to a specific software or hardware vulnerability, used to reference the same issue consistently across tools, advisories and reports. - [Hazard analysis](https://pictorab.com/glossary/hazard-analysis): Hazard analysis is the systematic identification of ways a system can cause harm, forming the basis for safety requirements, risk classification and the resulting safety case. - [Important product with digital elements](https://pictorab.com/glossary/important-product-with-digital-elements): Under the CRA, an important product with digital elements is one whose core function carries elevated cybersecurity risk, requiring stricter conformity assessment than default products. - [Notified body](https://pictorab.com/glossary/notified-body): A notified body is an independent conformity assessment organisation designated by an EU member state and authorised to assess products against specific legislation, including parts of the CRA. - [Product with digital elements](https://pictorab.com/glossary/product-with-digital-elements): A product with digital elements is any software or hardware product, and its remote data processing solutions, placed on the market with a direct or indirect logical or data connection to a device or network. - [SBOM](https://pictorab.com/glossary/sbom): An SBOM is a structured inventory of the components, including third-party and open-source dependencies, used to build a software product, used to track provenance and known vulnerabilities. - [Safety case](https://pictorab.com/glossary/safety-case): A safety case is a structured argument, supported by evidence, that a system is acceptably safe for a specific use in a specific context. - [Secure development lifecycle](https://pictorab.com/glossary/secure-development-lifecycle): A secure development lifecycle is a defined set of security activities integrated into each phase of product development, from requirements through design, implementation, testing and maintenance. - [SIL](https://pictorab.com/glossary/sil): SIL, defined in IEC 61508, is a discrete level expressing the probability that a safety function will perform as required, used to set the rigour of design and verification measures. - [Support period](https://pictorab.com/glossary/support-period): The support period is the length of time a manufacturer commits to providing security updates for a product with digital elements, which the CRA requires be appropriate to the product's expected lifetime. - [TARA](https://pictorab.com/glossary/tara): TARA is a structured method for identifying cybersecurity threats to a system, assessing their impact and attack feasibility, and deriving proportionate security requirements. - [Traceability](https://pictorab.com/glossary/traceability): Traceability is the documented, verifiable linkage between a hazard or risk, the requirement written to control it, the design that implements it, and the verification that confirms it. - [Vulnerability disclosure policy](https://pictorab.com/glossary/vulnerability-disclosure-policy): A vulnerability disclosure policy is a published statement describing how a manufacturer accepts, handles and responds to reports of security vulnerabilities in its products. ## Insights - [Insights](https://pictorab.com/insights): Engineering notes on safety, security and evidence. - [CRA reporting obligations begin 11 September 2026 — what operational readiness means](https://pictorab.com/insights/cra-reporting-obligations-2026): From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents. A practical view of what has to work operationally before that date. - [Traceability that survives review: from hazard to accepted evidence](https://pictorab.com/insights/traceability-that-survives-review): Why safety traceability fails under scrutiny, and how to structure the chain from scope and hazard through architecture, verification and evidence. - [Safety and security are one engineering chain, not two departments](https://pictorab.com/insights/safety-and-security-one-engineering-chain): Hazard analysis and threat modelling share a system model. Structuring them together produces stronger evidence and fewer contradictory mitigations. - [What reviewers actually ask for in a CRA technical documentation pack](https://pictorab.com/insights/what-cra-reviewers-actually-ask-for): Notes from preparing technical documentation packs for review: the questions that come back most often, and the gaps that generate them. - [Why SBOM programmes fail after the first generation run](https://pictorab.com/insights/why-sbom-programmes-fail-after-first-run): Generating a first SBOM is straightforward. Keeping it accurate, queryable and used is where most programmes quietly stop. - [Coordinating ISO 26262 and ISO/SAE 21434 without duplicating work](https://pictorab.com/insights/coordinating-iso-26262-and-21434): Functional safety and cybersecurity engineering share artefacts more than most programme plans admit. A practical view of where to align them. - [Turning hazard analysis output into verifiable requirements](https://pictorab.com/insights/hazard-analysis-to-verifiable-requirements): The gap between a documented hazard and a requirement that can actually be tested is where most safety cases lose their footing. - [Vulnerability handling processes that survive an audit](https://pictorab.com/insights/vulnerability-handling-that-survives-audit): A vulnerability handling policy and a vulnerability handling process are different things. An audit tests for the second. - [Safety cases for products with continuous software updates](https://pictorab.com/insights/safety-cases-for-continuously-updated-products): A safety case built for a fixed configuration does not survive a monthly update cadence. What changes when updates are continuous rather than occasional. ## Research programmes - [Research programmes](https://pictorab.com/projects): European research consortia Pictor takes part in. - [BUMBLE](https://pictorab.com/projects/bumble): Blended modelling for cross-disciplinary software and systems engineering. - [Health5G](https://pictorab.com/projects/health5g): 5G-enabled healthcare use cases across hospital, home and emergency environments. - [SafeCOP](https://pictorab.com/projects/safecop): Safe and secure cooperation of cyber-physical systems. - [AMASS](https://pictorab.com/projects/amass): An assurance and certification platform for cyber-physical systems. ## Company - [About Pictor](https://pictorab.com/about): Who we are and how we work. - [Contact](https://pictorab.com/contact): Talk to a senior practitioner. - [Careers](https://pictorab.com/careers): Senior consulting roles at Pictor. - [Partners](https://pictorab.com/partners): How we work with partners. - [Investor relations](https://pictorab.com/investors): Company facts and direction. ## Optional - [Sitemap](https://pictorab.com/sitemap.xml): every indexable URL. - [Machine-readable index](https://pictorab.com/llms.json): the same map as JSON.