CSSF eDesk — login, roles and the S3 filing channel

In Luxembourg the hardest part of a return is often not the return. It is that nobody in the firm holds the role that lets the file leave the building. eDesk is the CSSF’s own portal, and behind it sits an S3 file-exchange interface carrying a growing share of Luxembourg reporting. Both run on a role matrix the firm administers itself, authenticated by a certificate the firm has to procure — and neither can be arranged on the afternoon a deadline falls. This piece sets out the roles, the S3 configuration, how to tell an upload from an acceptance, and three worked cases.

1. What eDesk is, and what it is not

eDesk is the Commission de Surveillance du Secteur Financier’s digital portal for supervised entities, at edesk.apps.cssf.lu. It is two things bolted together: online procedures — forms a named person completes and submits — and an enrolment layer issuing credentials for machine-to-machine filing. It is not itself an obligation: those live in the circulars and the legal reporting framework for each entity type. The distinction matters when a plan says “eDesk is done” — what is done is access, not the return.

Three live procedures show the range. Major ICT-related incident notification arrived as an eDesk procedure under Circular CSSF 24/847, mandatory from 1 April 2024 for one set of entity categories and 1 June 2024 for the rest, displacing Circular CSSF 11/504. The DORA Register of Information has its own procedure; its window for the 31 December 2025 reference date ran from 11 February to 31 March 2026. And ICT incident and cyber-threat reporting under DORA is framed by Circular CSSF 25/893, which repealed Circular CSSF 21/787 and was itself amended by Circular CSSF 26/915 — payment institutions, e-money institutions and account information service providers all appear in its scope list.

2. Authentication: the certificate is the gate

The short answer for anyone arriving on a login question: there is no separate eDesk username and password. You sign in at edesk.apps.cssf.lu with a LuxTrust authentication means held personally, and if the entity has never enrolled anyone the first step is not a login at all — it is a “New advanced user request” the CSSF endorses on identification documents and a signed mandate. The rule is stated without qualification: only users authenticated through a LuxTrust token can reach eDesk, and therefore only they can obtain the keys that configure machine filing.

Two consequences follow, both discovered late by firms whose reporting function sits outside Luxembourg. First, lead time: the means must be ordered, identity-checked and activated before anyone can see the portal, which puts it on an authorisation project’s critical path. Second, identity in eDesk is personal — continuity across leave and turnover comes from enrolling a second individual, not from circulating credentials.

3. The role matrix the firm administers itself

eDesk devolves user administration to the supervised entity — efficient, and also where most access failures start, because the entity rather than the CSSF has to notice a gap.

The keystone is the Advanced User, created through a “New advanced user request” that the CSSF endorses on identification documents and a signed mandate. The Advanced User accepts or rejects the attachment of other eDesk users to the entity and grants rights and specific roles within it — but is an administrator, not a filer. Specific roles sit on top:

Read that as a dependency chain rather than a menu. Every specific role depends on an Advanced User existing first, and the Advanced User depends on a CSSF endorsement that involves paper.

4. The S3 channel: buckets, keys and two folders

For structured reporting the CSSF exposes an S3 interface — the object-storage protocol over a web service. The CSSF is explicit that here S3 means only the protocol and does not rely on any commercial cloud service; the principle is that of SFTP, over HTTPS standards.

Data is stored as objects — a file plus its metadata — inside buckets. An entity is linked to a bucket divided into two folders: submission for files going out, feedback for what comes back. Each report type has its own bucket.

Enrolment runs through the roles above. Once the Advanced User has designated an IT Expert, that person signs in to the eDesk IT management console at edesk.apps.cssf.lu/edesk-itmgt, uses “Create access”, selects the relevant service — the scope — then opens the entry to collect bucket, access key and secret key. The secret key displays only once. Access is revoked from the same screen.

Client configuration is deliberately unexotic: any S3-compatible transfer client for manual work, any S3-compatible SDK for automation, pointed at protocol S3, host s3.apps.cssf.lu, port 443; some clients need their URL style switched to Path. Two behaviours cause most first-day confusion — for each report type the IT Expert may have to create “submission” manually before the first upload, while “feedback” appears by itself; and files in both folders are cleaned 20 days after creation, making the bucket transport, never an archive. On security the CSSF is direct: the IT Expert monitors every credential created, and sharing credentials or uploading through a third party remains the sole responsibility of the entity.

5. Feedback is the acceptance — the upload is not

The published process has three steps: collection through the S3 system, formal verification, and a feedback — positive or negative. Nothing there treats a successful upload as the end of the story, and the CSSF states the receiving-side duty plainly: entities must ensure all feedback files are properly analysed and any rejected data corrected and resubmitted. Entities are also advised to validate files before submission — the cheaper half of the same control.

There are two ways to test before go-live: a dedicated testing environment, and an Echo service running in production for connectivity checks — the IT Expert creates an access on the Echo bucket, a dummy file goes into submission, and one immediate dummy feedback returns.

6. Worked example — the new institution with nobody endorsed

Facts: an e-money institution is authorised in October; its first reporting period closes on 31 December, with submissions due in the weeks after. The reporting function sits outside Luxembourg, nobody holds a LuxTrust authentication means, and the entity has never appeared in eDesk.

Which rule applies: three dependencies in series. Only users authenticated through a LuxTrust token can reach eDesk at all. Before any specific role can be granted, the entity must have an Advanced User, endorsed by the CSSF on identification documents and a signed mandate. Only then can that person grant IT Expert — and only an IT Expert can create the S3 access keys. Nothing in the chain parallelises, and two of the three steps involve a third party.

What the reporting lead does: treats enrolment as an authorisation-project task, not a reporting task. Orders authentication means for two named individuals in the week authorisation is granted; submits the advanced user request immediately; then writes the role map against the obligation map — which return needs IT Expert, which IT Incident Notifier, which DORA Reporting — with a holder and deputy for each.

Outcome: credentials exist before the first period does. The alternative is a January in which the problem is not the return but an endorsement sitting at the regulator, which no internal escalation shortens.

7. Worked example — the secret key nobody wrote down

Facts: an IT Expert opens the eDesk IT management console, clicks “Create access”, selects the service, and copies the bucket name and access key ID into the team runbook. The secret key sits behind an eye icon that was never clicked. Four weeks later the automation is built and the credential does not work.

Which rule applies: the secret key can be viewed only once, and if it is lost the credentials have to be reset. There is no retrieval path, and a reset produces a new access key too, so every place the old pair was configured has to change.

What the analyst does: treats “Create access” as a one-shot operation performed with the secret store already open, capturing four things: bucket, access key ID, secret key location and the scope the access covers. Each report type has its own bucket, so the register is per report type — and because revocation lives on the same screen, that register is also the list of what to revoke when a person or service ends.

Outcome: a five-minute setup instead of an unplanned change. Reset-and-reconfigure touches the automation, needs a deployment, and is discovered mid-window — when a change to a filing pipeline is least welcome.

8. Worked example — the return that uploaded cleanly and was rejected

Facts: a scheduled job pushes a quarterly file to submission and logs a successful transfer. The dashboard is green. Two months later a supervisory query arrives about data the CSSF does not appear to hold.

Which rule applies: the process has three steps, not one — collection, formal verification of the uploaded file, then a feedback that is positive or negative. Entities must ensure all feedback files are analysed and any rejected data corrected and resubmitted. And both folders are cleaned 20 days after creation, so by the time the query arrives the evidence has gone.

What the team does: moves monitoring off the transfer client’s exit code and onto the feedback folder. Alerts on negative feedback and — the step most often missed — treats no feedback as an exception, because an absent feedback and a positive one look identical on a dashboard that only watches for failures. Copies every feedback file into the evidence store on arrival.

Outcome: a rejection surfaces within a day and is corrected inside the window. The failure mode this replaces is not a visible error — it is a green dashboard on a return the CSSF never accepted, with the bucket emptied before anyone looks.

9. What still travels by other routes

eDesk and its S3 interface have not absorbed everything. A body of Luxembourg reporting still reaches the CSSF through externally operated transmission channels with their own security regime: files must be encrypted to the standards in Circular CSSF 23/833, and the entity must register its LuxTrust SSL certificate with the CSSF beforehand.

So the reporting map has two columns, and the ordering that holds up is: obligations first, then the channel each uses, then the role or certificate that channel needs, and only then the people. Formats come from each procedure’s own guidance: incident notification accepts structured .json through S3 as an alternative to the eDesk form, while the Register of Information goes as plain CSV inside a .zip on a predefined folder structure, with the entity’s LEI communicated to the CSSF in advance.

10. FAQ

11. What to do, today

• Confirm the entity has an endorsed Advanced User. If not, submit the request now — none of documents, mandate and endorsement is same-day.
• Order LuxTrust authentication means for two named individuals per filing responsibility.
• Write the role map beside the obligation map: who holds IT Expert, IT Incident Notifier and DORA Reporting, and which return each unlocks.
• Create S3 accesses with the secret store already open, and record bucket, key location and scope per report type.
• Monitor the feedback folder rather than the transfer client’s exit code, alert on absent feedback as well as negative, and copy every feedback file into your evidence store on receipt.
• Run the Echo connectivity check before the first production submission, and after any credential reset.

For the Irish equivalent of this enrolment-and-upload problem, see the Central Bank of Ireland Portal.

Related: CSSF legal reporting for payment and e-money institutions · Reporting channels compared across the EU · How a DORA register of information is built · The CSSF AML/CFT data collection