What the check covers
Use case and credential
Which business problem the credential solves, what it must prove, who issues, holds and verifies it – and when it gets revoked.
Data and data protection
The authoritative data source, a minimised data scope, the legal basis, and which personal data must never appear in logs.
Organisation and registry
Issuer or verifier role, the legal entity to register, business and technical responsibility, internal approval paths.
DID and key management
Who controls the DID, where private keys live, how rotation and recovery work – and what happens on compromise.
Integration and revocation
Triggers for issuance and revocation, embedding into your business applications, error cases and a realistic end-to-end test.
Security and operations
Threat model, monitoring and alerting, support and escalation, runbooks and a tested incident process.
Interactive checklist
swiyu Readiness Check
Answer each question honestly. The result is only as sound as your answers.
42 questions for a PoC that holds up
You work through six sections of seven questions each. At the end you see immediately whether your initiative is green, amber or red – and you can have a PDF report sent to you with recommendations per section and a prepared decision log.
Assess each question together with the business owners, architecture, security and operations. Mark exactly one status and document open decisions, owners and deadlines.
1. Use case and credential
Goal: make decisions visible. Not just demonstrate that the technology works.
1Which concrete business problem should the credential solve?
2What must the credential prove for the business case?
3Who issues the credential, who holds it and who verifies it?
4Which measurable benefit or which risk should the process improve?
5Which validity period and which time-based restrictions apply?
6Under which business conditions must the credential be revoked?
7Are the appropriate credential type and the intended format documented?
2. Data and data protection
Goal: make decisions visible. Not just demonstrate that the technology works.
1Which attributes are strictly required for verification?
2Which attributes must deliberately not be included in the credential?
3Which system is the authoritative and reliable data source?
4Are purpose, legal basis and internal approval for the data processing clarified?
5Can the verifier request only the attributes necessary for the purpose?
6Which events are logged, and which personal data must never appear in logs?
7Are retention, deletion and the exclusive use of suitable test data governed?
3. Organisation and registry
Goal: make decisions visible. Not just demonstrate that the technology works.
1Is it clear whether the organisation acts as issuer, verifier or in both roles?
2Which legal entity is registered and who may represent it?
3Who holds overall business responsibility for the use case?
4Who is responsible for technical setup, operations and changes?
5Which entries and evidence are required for the base and trust registries?
6How are credential schema, issuance and verification rules approved internally?
7Which external operators, suppliers or other dependencies are involved?
4. DID and key management
Goal: make decisions visible. Not just demonstrate that the technology works.
1Which DID is used and who controls it organisationally?
2How and in which environment is the key material generated?
3Where are private keys stored and how are they protected technically?
4Which roles may use keys and how is separation of duties implemented?
5How are rotation, expiry and controlled replacement of keys handled?
6How do recovery, emergency access and documented handovers work?
7Which steps apply on suspicion of compromise or loss of a key?
5. Integration and revocation
Goal: make decisions visible. Not just demonstrate that the technology works.
1Which business systems supply data or receive verification results?
2What technically triggers the issuance of a credential?
3Which business or technical approval is required before issuance?
4How is verification embedded into web, mobile or business applications?
5How are errors, retries, timeouts and cancellations handled?
6What triggers a revocation and how quickly does it take effect for verifiers?
7Is an end-to-end test with realistic system boundaries and test cases defined?
6. Security and operations
Goal: make decisions visible. Not just demonstrate that the technology works.
1Are the threat model and the most important abuse scenarios documented?
2Which events, errors and security indicators are monitored and alerted on?
3Are logging, data protection and access to operational data aligned?
4How are releases, configuration changes and dependencies controlled?
5Who takes on support, escalation and communication during incidents?
6Are there runbooks, assigned responsibilities and a tested incident process?
7Which open points block production operation, and what does the roadmap look like?
On its way
Check your inbox – the report is on its way. It can take a minute.
An independent offering by b-nova. Not an official partnership with the Swiss Confederation or swiyu.
Why these 42 questions
From real projects
The questions come out of work on e-ID and credential projects – not from a generic template.
A decision, not a demo
The check separates the technical demo from a PoC that holds up. That is exactly where most initiatives come apart.
Five critical control points
Owner, data source, key control, revocation and operations. If one of them is open, the initiative is not ready for a decision – regardless of the rest.
An honest result
Not a score that flatters you. One open control point means red, even if everything else is green.
Work on it straight away
The decision log in the PDF already lists your open points. You add the owners and the deadlines.
No strings attached
The report is free. Whether it turns into a conversation is up to you.
Found open points?
The swiyu Readiness Kit closes exactly those gaps – from use-case selection through DID and Generic Issuer/Verifier to production operation.