COMPLIANCE PLATFORM · CRA & TYPE APPROVAL
Conformityyou can prove.
A product lifecycle that will not let a step be skipped — from cybersecurity classification through BOMs, threat analysis, supplier requirements and update planning, to a technical file and an EU declaration assembled from the record rather than retyped.
— The spine
Eleven states, one direction.
- Draft
- Classified
- Configured
- BOMs collected
- TARA approved
- Requirements baselined
- Supplier accepted
- Update plan approved
- Conformity ready
- CE authorised
- End of support
Transition refused
3 of 56 allocated requirements are unaccepted by Tier-1 supplier “Meridian”. Resolve or record a deviation to continue.
A gate returns the reason, not a generic error — and nothing advances without it
A product moves forward only. Every transition is written to the audit log in the same transaction that moves the state, so the record and the reality cannot disagree.
- EU CRA
- ISO/SAE 21434
- UN R155
- UN R156
- AIS-189
- AIS-190
01 — The problem
The file is only as strong as the step nobody checked.
Placing a product with digital elements on the market now means producing an evidence chain: a defensible classification, a bill of materials, a threat analysis, requirements traced to threats, supplier agreements covering the requirements they own, an update plan, a technical file, and finally a declaration somebody signs their name to.
Assembled by hand — across documents, spreadsheets and email threads with suppliers — that chain has gaps by construction. A requirement gets allocated and never accepted. A component enters the build after the BOM was collected. Evidence goes stale quietly, and the gap is found by an assessor rather than by you.
This platform makes the chain a state machine. Each step is a gate: it passes with the evidence recorded, or it refuses and tells you exactly what is missing.
02 — What runs inside
The work, module by module.
Classification & routing
Classify the product and the platform routes it to the correct conformity procedure — self-assessment, notified body, or European cybersecurity certification — instead of leaving the decision to a reading of the regulation.
BOM collection
CycloneDX and SPDX software, hardware and cryptographic bills of materials, parsed and validated on import rather than accepted as an attachment, with coverage rolled up across the portfolio.
Vulnerability monitoring
Components matched continuously against public advisory and known-exploited sources. When something becomes exploited, the reporting clock starts and is recomputed on every read.
Threat analysis intake
The TARA is imported verbatim from the analysis tool and never silently altered — assets, threats, goals and requirements with their risk and assurance levels intact.
Supplier requirements
Allocation, an NDA-gated package with a frozen snapshot, per-requirement acceptance or a formal deviation, and drift detection when the baseline moves underneath an issued package.
Technical file & declaration
The Annex VII file assembled to the eight elements of Article 31 with per-element status, and the declaration rendered from the recorded evidence.
- Format
- CycloneDX 1.6
- Software components
- 412
- Hardware components
- 38
- Cryptographic assets
- 11
- Unresolved licences
- 0
CycloneDX and SPDX parsed on import — not accepted as an attachment
Deadlines are recomputed on every read — a stopped scheduler cannot hide an overdue clock
- Package issued
- under NDA · 12 Jun
- Requirements allocated
- 56
- Accepted
- 53
- Deviations recorded
- 2
- Open
- 1
- Snapshot drift
- none
The issued package is frozen — if the baseline moves, the drift is flagged rather than silently applied
- Product descriptionpresent
- Design & developmentpresent
- Risk assessmentpresent
- Applied standardspresent
- Vulnerability handlingpresent
- SBOM (on reasoned request)present
- Conformity assessmentpartial
- EU declarationpending
The eight elements of Article 31 — assembled from the record, not retyped
03 — On screen
The modules, running.
Five of the six, on a demo tenant with demo data. Not a rendering of the product — the product.
Product classification · question 1 of 5 · CRA Annex III
SBOM viewer · CycloneDX and SPDX releases · 47 components
PSIRT view · three CVEs marked actively exploited
Traceability · CVE to risk to requirement to evidence
Conformity assessment · four stages to the declaration
04 — Why gates
A refusal is more useful than a warning.
Most compliance tooling warns. A warning is a row in a list that somebody will action later, and later is how a product reaches a declaration with a requirement nobody accepted.
Here the transition simply does not happen, and the refusal names the reason: which requirements, which supplier, which document. There is no override that quietly moves the state — the only way forward is to resolve it or record a deviation, and both are part of the file.
This is not a philosophical preference. Run the same programme on warnings and the failure is silent: a product reaches authorisation with most of its allocated requirements never actually accepted, and nothing in the file says so. A gate is the difference between finding that in your own system and having an assessor find it in your submission.
A gate that can be overridden is a warning. This one cannot, so it is a guarantee.
05 — Built for
Nine roles, because the real table has nine people.
OEM homologation & compliance
You own the submission and the declaration. You need to see, at any moment, which products are blocked and on what — without asking six people for a status.
Tier-1 product security
Requirements arrive from several customers and flow down to several suppliers. You need allocation, acceptance and deviation as records rather than as an inbox.
Tier-2 supplier
You receive a package, an NDA and a deadline. You need to accept requirements, raise a deviation and be finished — without being asked to buy a platform of your own.
06 — In practice
What it looks like in your week.
Four moments where the difference between a managed lifecycle and a folder of documents becomes obvious.
Onboarding a product nobody documented
An existing product needs to be brought into conformity and the evidence is spread across four teams. Classify it, import the BOMs, attach the analysis, and the lifecycle tells you exactly which gate you are standing at and what it wants. The backlog stops being a discussion and becomes a list.
The morning a component becomes exploited
A vulnerability in a library you ship moves onto the known-exploited list. The platform has already matched it to the products that contain it and started the reporting clock, so the first question — which of our products, and how long have we got — is answered before anyone has opened a spreadsheet.
Getting a supplier to actually commit
Requirements are allocated, the package is issued under NDA with a frozen snapshot, and each requirement is accepted or formally deviated by the supplier themselves. When the baseline later moves, the drift is flagged against the issued package rather than quietly applied — so nobody discovers the mismatch at the audit.
The declaration, at the end
The technical file assembles to the eight elements of Article 31 from evidence already in the system, and the declaration renders from that record. Nothing is retyped into a document, which means nothing can disagree with the file it came from.
07 — What you get
The artefacts an assessment asks for.
Bring one product and its evidence.
We will take a product you are already carrying to a declaration, run it through the lifecycle, and show you precisely where the chain has a gap today.
Request a walkthrough09 — Start here
Bring us the file you are least sure about.
Most conversations start with a gap assessment, or a type approval submission that is closer than it feels. Either is a good place to begin.
Direct
- Email[email protected]
- Phone+91 98672 75102
- Book a callcalendly.com/contact-autosifu
Jaipur · registered office
Plot No. 8, ABS Plaza, Chanakya PuriJagatpura, Jaipur – 302017, RajasthanAUTOSIFU Pvt Ltd · India