EUDAMED actor setup: identity, mandate and user access before portfolio work
Actor onboarding concerns the economic operator and Actor ID/SRN, rather than registering every device record. The acquired Commission page describes competent-authority assessment, a signed information-security declaration, non-EU manufacturer mandate information and subsequent user access. Prepare those actor facts before commissioning portfolio registration or M2M work.
Evidence retrieved 2026-10-06. Source versions and topic-specific limits are listed below.
Sourced criteria · EU
What changes the service scope?
Decision or task
What the source describes
What to prepare
Which actor identity is being registered?
The page describes an actor registration request for Actor ID/SRN, an EU-wide economic-operator identifier, with national competent-authority assessment. [1][2][3][4]
Map the actual legal entity, role and authority process; keep actor identity separate from device/UDI identifiers.
Which signed declaration is prepared?
The page specifies a signed declaration on information-security responsibilities for actors. [5]
Use the current official template and agree its authorised signatory and document control; this brief should not contain security tokens.
What non-EU manufacturer mandate is needed?
The page describes an active authorised representative and mandate summary accompanying the non-EU manufacturer’s registration request. [6]
Reconcile manufacturer, representative, mandate coverage and request details before submission.
Who obtains user access afterwards?
The page describes an access request for people who intend to act on behalf of a registered actor. [7]
Name account/access owners and permitted roles; scope later device-data and M2M tasks separately.
Actual actor eligibility, competent-authority decisions, current module applicability and buyer documents remain incomplete. This is actor onboarding, not approval of a device or a public registry API.
A scoped evidence and handoff plan
Use this checklist to gather your business or product details before speaking with a specialist. The items below explain what to record and suggest useful supporting documents. You can add your own answers in the editable project brief.
Which actor identity is being registered?
Map the actual legal entity, role and authority process; keep actor identity separate from device/UDI identifiers.
Useful evidence: Entity/establishment/role record and actor-request owner.
Which signed declaration is prepared?
Use the current official template and agree its authorised signatory and document control; this brief should not contain security tokens.
Useful evidence: Current declaration/template, authorised signatory and controlled file location.
What non-EU manufacturer mandate is needed?
Reconcile manufacturer, representative, mandate coverage and request details before submission.
Useful evidence: Representative identity, active mandate and required summary document.
Who obtains user access afterwards?
Name account/access owners and permitted roles; scope later device-data and M2M tasks separately.
Useful evidence: User/role/access matrix and handoff to portfolio-data owners.
Work packages and dependencies
Conditional: Actor identity, signed documents and user-access setup — For this work package, agree the supported criteria, evidence access, covered entities/products and unresolved facts in the table above. Additional services require their own justified scope.
Optional: Representative mandate where the actor context requires it — For this work package, agree the supported criteria, evidence access, covered entities/products and unresolved facts in the table above. Additional services require their own justified scope.
Questions for providers
Which exact actor, product or processing facts support the quoted scope, and what is still unresolved?
How will the listed records reach the responsible people, and who owns each change or authority request?
Which tasks and entities are excluded from the agreement, and which additional services need a separate assessment?
Sources and data dates
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.
