EUDAMED M2M connection: actor administrator, Access Point and environment handoff
The acquired EUDAMED M2M prerequisites describe eDelivery setup, a registered actor with a Local Actor Administrator, Access Point Party ID, module-specific security keys and Playground onboarding before Production access. These are connection and operations tasks, separate from initial actor identity and routine data preparation.
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 eDelivery setup and party identity are used?
The prerequisites describe installed/set-up eDelivery-compatible product/service and the Party ID of the Access Point used for exchange. [1][3]
Document the actual Access Point/operator and configuration ownership; verify the current technical specification/version separately.
Who administers the actor connection?
The page requires actor registration and an active Local Actor Administrator profile. [2]
Confirm the represented actor, authorised administrator and account/backup ownership; this is not general public API access.
How are module-specific secrets controlled?
The prerequisites describe a security key for every module used for M2M exchange. [4]
Agree secret generation, secure storage, renewal and support ownership. Do not put actual tokens into this project brief or public requirements.
What proves the environment handoff is ready?
The prerequisites describe successful Playground onboarding before an Access Point in Production. [5]
Keep environment endpoints/credentials separate and agree onboarding/test evidence before production activation; do not reuse Swiss REST rules as EU eDelivery specifications.
The current production service/entity XSD versions, complete business rules, module privileges and buyer system facts remain incomplete. Prerequisite guidance alone does not certify an integration or establish unrestricted access.
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 eDelivery setup and party identity are used?
Document the actual Access Point/operator and configuration ownership; verify the current technical specification/version separately.
Useful evidence: Access Point architecture, operator/Party ID record and technical-version register.
Who administers the actor connection?
Confirm the represented actor, authorised administrator and account/backup ownership; this is not general public API access.
Useful evidence: Actor/SRN record and authorised LAA/role matrix.
How are module-specific secrets controlled?
Agree secret generation, secure storage, renewal and support ownership. Do not put actual tokens into this project brief or public requirements.
Useful evidence: Module/access inventory and secret-management responsibility plan without secret values.
What proves the environment handoff is ready?
Keep environment endpoints/credentials separate and agree onboarding/test evidence before production activation; do not reuse Swiss REST rules as EU eDelivery specifications.
Useful evidence: Playground onboarding evidence, environment matrix and production handoff acceptance plan.
Work packages and dependencies
Conditional: Access Point, administrator, security and environment integration — 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: Separate portfolio mapping/validation operations — 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.
