A German automotive supplier exploring Catena-X should begin with one approved certificate, one receiving partner and a demonstrable update process. The engineering deliverable is a dependable exchange between existing business records and the chosen data-space service. A connector demonstration alone does not prove that the right certificate will remain available after an organisational change or renewal.
There is a concrete 2026 signal behind this opportunity. Catena-X and IDSA announced the Data Space Accelerator on 8 June 2026, with certificate management among its initial use cases. The announcement concerns a specific programme and participation conditions; funding eligibility should be checked directly. For software buyers, the useful implication is that productive data exchange deserves its own project scope.
Start at the quality manager’s desk
Consider a fictional German component supplier whose quality certificates live in a document system while customer relationships live in an ERP. A quality manager knows which document is current, but customer service repeatedly uploads copies into different portals. An integration can help only after those systems agree about the issuing organisation, covered site, certificate type and validity period.
Walk through an actual renewal with the quality manager. Ask how an approved replacement becomes authoritative and whether historical versions must remain accessible. Record who can resolve disagreement between a document name and the structured ERP record. That decision belongs in the business process before an engineer writes a mapping.
Draw the boundary between purchased service and custom work
The German economic ministry’s Manufacturing-X overview describes interoperable industrial data ecosystems and cross-company use cases. It does not mean every supplier should build its own data-space infrastructure.
Compare the capabilities of the selected service with the company’s internal workflow. Existing onboarding, identity or certificate-management products may already cover much of the requirement. Custom development is justified where approved internal records, permission decisions, monitoring or support processes need to connect to that service.
Ask the vendor to identify each dependency by owner. The statement of work should distinguish your ERP adaptation, the provider’s platform configuration, partner onboarding and any separate certification activity. A software integration engagement does not itself confer Catena-X certification.
Design the certificate record before the dashboard
Create a small data contract agreed by quality, operations and engineering. It should specify:
- ▸The internal identifier for the organisation and covered site.
- ▸The certificate category and source document reference.
- ▸Approval status, validity dates and the person responsible for corrections.
- ▸The relationship between an old certificate and its replacement.
- ▸Which partners may receive which record and attachment.
- ▸The source timestamp used to explain when information last changed.
Treat these as project fields to validate against the selected service and current standards, not a claim that every platform uses the same schema. Keep a mapping example with real field names and synthetic values in the delivery documentation.
Make replacement the central acceptance test
An initial upload is the easiest part to demonstrate. A stronger test starts with an existing approved record, introduces a replacement, and follows the result through the complete chain.
Use a controlled test partner. Publish the first version, verify the receiver’s view, approve a renewal internally, and observe which version becomes current. Then replay the same update and interrupt the connection before confirmation. The application should reveal what it knows and what remains uncertain without creating a second business record by accident.
Also test a certificate that has expired without a replacement. The quality manager needs a visible exception with an accountable owner. Automatically extending validity because a field is missing would turn a technical convenience into misleading business information.
Partner permissions need a business explanation
The permission model should answer a plain question: why is this organisation entitled to this certificate? Avoid granting a customer group broad access merely because its members share a similar name. Separate partner identities from staff identities, and record how access changes when the commercial relationship ends.
For the pilot, ask a reviewer to follow the approved access path and then attempt an unauthorised one using test accounts. Include a partner whose access was removed after a previous successful exchange. These cases expose gaps that a dashboard showing only successful transfers will conceal.
Give support staff a useful exchange history
Support needs the internal record reference, intended recipient, attempt time, latest known outcome and a safe next action. It does not need unrestricted access to every partner document. Build those views around actual support responsibilities.
Specify how the team distinguishes a mapping rejection from an unavailable external service or a missing partner permission. Define which failures are safe to retry automatically and which need human correction. Keep credentials and unnecessary document contents out of routine diagnostic messages.
A handover rehearsal should involve someone who did not build the integration. Give that person an expired test record and a failed transfer, then ask them to locate the cause and follow the documented recovery process.
Buy a bounded result
The first release can cover one certificate family, one source system and one agreed partner workflow. Acceptance evidence should include field mappings, access tests, replacement behaviour, recovery results and a named operating owner. Broader traceability or carbon-data exchanges can be estimated after those foundations work.
TuniCyberLabs can help scope the custom software around an existing data-space service. Review our custom software development services, then describe your certificate workflow. Include your source systems, selected provider and the partner journey you need to prove. Our handover guide can help define what your team should own at completion.