They should treat certification timing as a deployment risk and not a procurement afterthought. If an onboarding path cannot be certified before the deadline, it should not be counted on for the regulated flow. The safer choice is to redesign the onboarding route early enough to avoid a last-minute compliance gap.
Why certification timing has to be treated as a go live dependency
When eID is required, the certification date is part of the control boundary, not just the project plan. A route that is not certified in time cannot be assumed to satisfy the regulated onboarding flow, even if the technical build is complete. That means the organisation should treat the certification path as a gating dependency and design the operating model around the deadline, not around optimism.
The practical implication is that procurement, implementation, legal review, and certification evidence gathering all need to move early enough to leave room for rework. If the selected route is still uncertain close to the deadline, the safer decision is to avoid making it the default path for a regulated population. The question is not whether the solution might eventually pass, but whether it is dependable on the date it is needed.
For organisations working with digital identity and wallet-based onboarding, the useful planning reference is the Digital Identity, eID and Identity Wallets Guide, which helps frame how eID, wallets and relying-party flows fit together. That matters because certification often depends on the exact trust framework and onboarding pattern, not just the identity concept in the abstract.
What happens when you assume certification will arrive later
The main failure mode is a last-minute compliance gap: the organisation ships an onboarding route that cannot legally or operationally be used for the regulated flow, then has to improvise under deadline pressure. That creates avoidable friction for customers, internal teams, and compliance stakeholders, and it can force manual workarounds that are harder to govern than the original design.
Another common issue is false confidence from partial readiness. A route may be technically integrated, but if certification evidence, assurance artefacts, or formal approval are incomplete, the route is still not fit for the required use case. In practice, the problem is less about whether the system works and more about whether the organisation can prove it works under the required assurance model.
That is why identity assurance controls matter here. The relevant external baseline is NIST SP 800-63 Digital Identity Guidelines, because the issue is not generic onboarding speed but assurance, proofing, and authenticated trust in the identity flow. Where certification and assurance do not line up, the regulated path should be treated as unavailable until the evidence is complete.
How to redesign the onboarding route without creating a deadline trap
The strongest response is to separate the regulated path from the fallback path early. If the certified route may miss the deadline, build an alternative onboarding journey that does not rely on the uncertified component, or defer the regulated use of that route entirely. This avoids a situation where the business promises a flow that only exists if certification lands on time.
In parallel, the organisation should validate the trust model, evidence requirements, and dependency chain for the alternative route before relying on it. In many cases the better design choice is a narrower, simpler onboarding flow that can be certified sooner rather than a broader one that creates schedule risk. Simpler paths are often easier to evidence, easier to operate, and easier to defend if a regulator or auditor asks why the original route was not used.
For teams that want a control-oriented reference point, the NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it ties identity, access, auditability, and system integrity to an implementation discipline. The point here is not to map every control mechanically, but to ensure the onboarding decision is backed by a defensible security and assurance process rather than a delivery assumption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | eID timing depends on identity assurance and authenticated trust in the onboarding flow. |
| Recommendation — Align the onboarding route to the required assurance level before using it for the regulated flow. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The issue is whether the required identity path is ready and trustworthy at go-live. |
| AU-2 — Audit Events | Certification readiness depends on evidence that the route can be proven and reviewed. | |
| Recommendation — Require the identity path to satisfy authentication controls before launch. Capture the evidence needed to show the onboarding route is fit for regulated use. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The onboarding route determines who can access the regulated flow and when. |
| A.5.31 — Legal, statutory, regulatory and contractual requirements | The question is driven by meeting a required eID obligation on time. | |
| Recommendation — Gate access to the regulated onboarding flow until the certified route is available. Map the launch decision to the applicable regulatory requirement before go-live. | ||
Practitioner Guidance
What to prioritise: Decide early which onboarding route is acceptable without the delayed certification path, and freeze that decision before the deadline pressure starts. If there is no acceptable fallback, stop treating the uncertified route as part of the regulated launch plan.
What to verify: Confirm that the evidence needed for certification, approval, and operational use is on track as a single workstream, not three separate ones. If any of those streams is slipping, assume the route will not be ready in time until proven otherwise.
Practitioner takeaway: The safest operational stance is to plan for certification to slip, because a regulated onboarding path that depends on a future approval is not a launch-ready control.