Regulation & Compliance

Help on Regulation and Compliance

K | Data protection

Yes, a distinction is made between whether the signatories have agreed to the terms of use of Switzerland or the EU or both. All data is also processed by Swisscom (Schweiz) AG for Swisscom IT Services Finance S.E. in Vienna.

The Distinguished Name contains either the person’s first name, surname and country of birth/registration or home country, or a pseudonym with a serial number that can be uniquely traced back to a person by the registry. Organisation names are only permitted in special cases

Switzerland is not in the EU and has therefore not introduced EU legislation, the so-called General Data Protection Regulation (GDPR). In reality, the GDPR is also applicable if the companies are based in Switzerland and offer services in the EU.

Swisscom is therefore subject to the same data handling obligations as all other organizations that have to comply with the GDPR:

  • obtain the consent of the person whose data are processed
  • “Privacy by design” and “Privacy by default” guarantee
  • appoint a data protection representative
  • create a list of processing activities
  • report violations of data protection to the supervisory authority
  • conduct a privacy impact assessment

All applications which concern data protection and are used for data processing, e.g. also the RA-App must be GDPR compliant. Swisscom provides information on this on its pages:



with corresponding data protection declarations according to GDPR.

Switzerland has always been and is considered as a secure third country pursuant to Art. 45 GDPR (data transfer based on an adequacy decision), i.e. the usual authorisations as with other third countries (e.g. the U.S.) are not necessary. Thanks to its Data Protection Act and the ongoing adaptation to the GDPR, Switzerland has an “adequate level of protection for the transfer of personal data” in accordance with EU criteria, i.e. it must in fact be treated as an EU country when transferring data:

As part of its ongoing audits, Swisscom must ensure that all the strict data protection requirements necessary for the issue of digital signatures are complied with, both vis-à-vis the certification authority in Switzerland and vis-à-vis the conformity assessment body in Austria. This means that, in addition to self-declaration, trust service providers and certification services are obliged by legislation and the international standards applied, such as ETSI 319 401, to demonstrate and have audited appropriate data protection for all personal data.

The data protection requirements to be demonstrated and audited also apply to the registration authority activities – a task of a trust service provider and certification service provider. Thus the RA app as part of the registration process must ensure data protection and privacy. The RA-App itself does not store any personal data permanently. No data can be exported either. As soon as the identification has been completed, the data is transferred signed by the RA agent as so-called evidence. This evidence is stored at Swisscom’s RA service under strict security conditions (e.g. 4-eye access). Only a few people have access to this data and may only pass it on based on a court order or are allowed to check the quality of the identification. According to the law, Swisscom has unlimited liability for the proper execution of the signature and thus also the identification.

RA Master Agents have web access to a portal in which they can view all persons identified by RA Agents with their surname, first name, expiry date of the ID document and mobile phone number. The ID documents and photos (so-called “evidence”) are not accessible or exportable.

Swisscom is legally obliged to record personal data for the signature. It is therefore responsible for this data. This means that Swisscom cannot play the role of a data processor, even if it receives e.g. employee data from a customer company for the signature. Swisscom has a legal mandate like that of telecoms or postal service providers. Furthermore Swisscom has a legal contractual relationship with the signatories with the terms of use. In this agreement, the signatory also accepts the use of data.

With the RA app, Swisscom transfers the recording of identity data to an external service provider, which is referred to in the contracts as the “RA agency”. The GDPR requires in this case an order processing contract. The RA agency must therefore comply with the obligations for order data processing.

Compliance with the GDPR order data processing is also required in purely Swiss projects. There are two reasons for this:

  • On the one hand, it can rarely be guaranteed that persons identified in Switzerland are not EU citizens who are subject to the market principle of the GDPR,
  • On the other hand, the RA app cannot be used in such a way that only persons for Switzerland are identified, i.e. order data processing always takes place for Swisscom IT Services Finance S.E. in Vienna as well.

There are projects in which Swisscom relies on legally recognized and audited identification procedures with third parties. A typical example is a bank that carries out a presence identification of a person as part of its KYC process. In this case, Swisscom receives a copy of the bank’s data for its own business purposes (signature). Order data processing is not necessary here, as there are two parties responsible for the data. Conversely, the Joint Controllership Principle of the GDPR is not applied here either, as the responsiveness of data does not serve the same business purpose and both parties do not act responsibly in the sense of a common business purpose. The bank acts for its business purpose, e.g. opening an account, and Swisscom pursues its business purpose of issuing signatures. Nevertheless, in this case our contracts on the “delegation of registry activity” also contain a minimum of provisions on how to proceed regarding data protection and the GDPR.

In the case of a remote signature, Swisscom keeps and manages the keys to the signature certificates in trust. In the case of a personal signature, the signature certificates are only generated for the signature and lose their validity after approx. 10 minutes. Company certificates for seals are valid for up to 3 years. According to the law, the private key must be stored on a (qualified) signature creation device. The memory for this is a device which is mainly designed for key storage, the HSM (Hardware Security Module). It is subject to strict regulation, auditing, in terms of security standards and access to this device. Signatures in the EU and Switzerland are subject to particularly high security standards, which are only available from a few HSM manufacturers worldwide.

L | Legal and regulatory topics

Adobe is a U.S. American supplier of a software that can display PDF documents. The most prominent and widespread product is the so-called “Adobe Acrobat Reader”. This enables the verification of certificate-based signatures. Whether a signature is valid and thus displayed with a green tick depends on many aspects:

  • Adobe has its own set of rules, which classifies issuing CAs from trust providers or certification service providers as “trustworthy”. These are listed in a so-called Adobe Trust List (AATL). Even if not included in the service description, Swisscom always endeavours to be listed here. In addition, the listed companies must pay annual fees for this entry and file in their self-assessment. According to Adobe, eIDAS trust service providers are considered trustworthy if they have also concluded a contract with Adobe.
  • Adobe offers a variety of settings that can lead to a completely different validation: For example, instead of Adobe’s trust list, Microsoft Windows’ trust list can also be used, which usually only maintains trust service providers that also issue SSL or e-mail certificates. However, the check can also be based on a time given by the computer clock and not on the time stamp in the document.

This means that you cannot rely on the validity of a signature in Adobe, but you get information about whether changes have been made to the document since the signature was set and how the signature certificate looks like.

Both should be IT people who are familiar with the application. It does not have to be a person with the official role “Privacy Deputy”. Swisscom simply wants to retain the 4-eyes principle here. The roles are: To be able to provide information about the administration of the user application (who has access, what could an administrator manipulate, where might there be a hitch, SSL connection to Swisscom) and about topics such as virus protection, access control in general, etc. at the person responsible for security.

On the one hand, an internal company can become a Swisscom reselling partner for other companies in case there is a huge volume planned. In this case, the payment flow goes directly only through this individual company. One company can also assume complete responsibility for the operation of the subscriber application. Even then, invoices will only go through this company. It can then identify employees of the other companies.

If all companies want to operate the subscriber application independently (with their own liability and responsibility) and also want to provide RA agents themselves, a separate contract is required for each company.

Every year, Swisscom invests large sums in ongoing audits. However, to be able to place the offer of a trust service provider on the market at a reasonable price, this service is offered in a standardised form. That means in particular:

  • The customer must adhere to the standard ordering process with the standard contract documents released by the auditors.
  • Further assessments by participants and the examination and acceptance of own contract texts are not included in the offer.

Many aspects of the trust service provider are subject not only to conditions in the execution of the service but also in the specification of important obligations, liability regulations and cooperation services in the contract documents. Therefore, these contract documents are also subject to auditing or are also submitted to the state conformity assessment bodies. Therefore, no changes to the legal system can be accepted, nor can contractual enclosures of the participant be accepted, especially if they are subject to foreign, applicable law.

If it is nevertheless necessary to adapt contractual texts, add contractual regulations (e.g. your own Code of Conduct, Data Protection Declaration, NDA, etc.), process special assessment questionnaires or if you have even discovered errors or unclear formulations, please report these to our product management.

If any errors or ambiguities are apparent, a corresponding change process is initiated by product management and implemented as quickly as possible.

For the evaluation of other questions, a processing team is formed that draws on the relevant experts (e.g. legal department, security officer, compliance officer, etc.) and carries out an evaluation of the request. A project specific fee of CHF 6,000 is due for this. If the team of experts was not able to work out a solution directly, it will prepare an answer and an offer, which will present and assess further steps on the part of Swisscom.

No, only for the operation of the signature application no certification and no audit is required. Within the scope of a “configuration and acceptance declaration”, the customer makes a self-declaration to operate the signature application properly, i.e. not to exchange the hash of a document and to actually display the document to be signed to the customer (WYSIWYS = “What you see is what you sign”). Data traffic between the signature application and Swisscom should be encrypted and basic protection against viruses and attacks should be guaranteed as with any other system. An official audit with certification can only be necessary if the system has its own identification, especially in relation to its own authentication method. In Switzerland, identification with Swisscom authentication methods can be dealt with in a simplified manner by means of a suitable “implementation concept” submitted by the customer and approved by Swisscom; in the EU, an official audit is generally necessary. As a rule, an authentication method must always be certified, as this should ensure “sole control” to the signing certificate (called “sole control” in the ETSI context).

In principle, the company must appoint representatives. These representatives should either be the registered representatives according to the commercial or business register, or employees with appropriate powers of attorney signed by the registered representatives. In any case, the persons must be personally identified with our RA-App. In Switzerland, only companies registered in the UID Register can order seals. With the seal, the SSL access certificate between the signature application at the customer and Swisscom serves as authentication of the company. The access certificate must therefore be handed over by the representative of the organisation. With the advanced seal, simple delivery is sufficient; with the qualified seal, a joint handover ceremony takes place at which the access certificate is jointly generated. The private key must be stored on a cryptodevice (FIPS 140-2 level 2 minimum).

In principle, Swisscom has unlimited liability under the law for the incorrect issue of qualified certificates. In the case of advanced certificates, this liability can be limited. Swisscom is also compulsory insured for this purpose. In the event of errors in the signature application (e.g. the exchange of a hash of a document) or errors in identification by third party registries, Swisscom in turn will hold these third parties liable. In order to avoid the risks of liability, high demands are placed on the issuance and contract process and the possibility of auditing the third parties involved is generally required.

Swiss legislation, i.e. the Swiss Federal Electronic Signature Act (ZertES/SCSE), provides the requirements organizations  have to fulfill in order to be recognized as a certification service. The accredited accreditation body for the accreditation of Swisscom as a certification service in Switzerland is KPMG (Accreditation No. SCESm 0071). It issues a conformity assessment certificate (available at  The Swiss Accreditation Service SAS maintains a list of accredited certification services: Link

With the entry into force of the Regulation on Electronic Identification and Trust Services for Electronic Transactions in the Internal Market of the European Union (eIDAS), the basis has been created for legally valid electronic communication and secure electronic identification throughout Europe. With the help of trust services such as electronic signatures, seals, time stamps, delivery services and certificates for authentication, companies, administrations and private individuals can exchange digital documents such as offers, orders, contracts etc. within the European Union on a uniform legal basis. Thus, the new EU regulation replaces the national signature law and signature regulations.

Under this Regulation (EC) No 910/2014/EU (eIDAS Regulation), national Trusted Lists have a constitutive effect. In other words, a trust service provider and the trust services it provides will be qualified only if it appears in the Trusted Lists. Consequently, the users (citizens, businesses or public administrations) will benefit from the legal effect associated with a given qualified trust service only if the latter is listed (as qualified) in the Trusted Lists.

Swisscom’s subsidiary in Austria “Swisscom IT Services Finance S.E.”, Vienna have been included in this list of trust with qualified certificates and seals:

Swisscom IT Services Finance S.E. has mandated Swisscom (Switzerland) Ltd to operate the trust service and has also delegated the registry authority activities to Swisscom (Switzerland) Ltd. Swisscom (Switzerland) Ltd. thus offers the service to the market and also accepts contractual documents on behalf of Swisscom IT Services Finance S.E..

Swisscom can only confirm that it can issue qualified signatures in both legal systems in accordance with the eIDAS Regulation of the EU and the ZertES Act of Switzerland. The qualified Swiss signatures are only recognised as qualified in Switzerland and the eIDAS qualified signatures in the EU.

Whether the qualified signature is compliant for any contract must always be verified by a lawyer. Swisscom may not provide any legal information in this regard. This is not only related to the signature, but also to other points that may be agreed in contracts. For example, the requirement for “return by registered mail” may mean that an electronic signature cannot be executed at all, as a postal paper route is mandatory.

In both the EU and Switzerland legal systems, the reversal of the burden of proof (and in Germany also prima facie evidence compared to visual evidence) applies in principle to qualified signatures. This means that an opposing party must prove that the qualified signature was not properly executed if it is contested. And, of course, Swisscom can provide KPMG-certified verifications to prove that the qualified signature has been duly executed.

The retention periods for identity verification and the activity journal and thus also the periods of proof are 11 years in Switzerland and 35 years in the EU. Swisscom generally uses the long-term validation standard of ETSI (LTV).

Long term validation means validating a signature in such a way that it remains valid for a long time. The LTV validation only allows validation as long as the root certificate for the timestamp has not expired. It is therefore advisable to time stamp the documents again before expiration if long-term evidence is to be preserved, so that the integrity and meaningfulness of the signature evidence continues to be ensured.

In principle, PDF documents should also be managed in secure archives. A situation can arise in 5, 10 or 20 years in which the signature algorithms are “cracked”, i.e. the integrity or authenticity could no longer be guaranteed. Good archiving systems therefore provide for regular resignation, e.g. with a time stamp, which always uses the latest algorithm and thus ensures the integrity of the document.

The web offers different links with optimized procedures for this, e.g. “Archisig”. The German BSI has also published a technical guideline “Preservation of the evidential value of cryptographically signed documents”. It is the specification of technical security requirements for the long-term preservation of the evidential value of cryptographically signed electronic documents and data together with the associated electronic administrative data (metadata).

A middleware defined for these purposes (TR-ESOR middleware) in the sense of this guideline comprises all those modules and interfaces which are used to secure and maintain the authenticity and to prove the integrity of the stored documents and data.

Experience has shown that transition periods can last from 3 months to 2 years.


After termination of the contract existing valid seal certificates will be revoked.

The way in which such a “shutdown” scenario is to be done is regulated by law: The CP/CPS of the certification service or trust service describes the exact procedures. There must be a shut-down plan, and the notified supervisory authority or OFCOM will usually appoint a successor who could offer the service to customers. This successor will normally also receive the Certificate Revocation List and thus the list of validity of the certificates, provided that Swisscom does not publish them itself. The list will continue to operate for years, so that the validity of signatures can continue to be verified. The evidence on the registrations for the service must be kept according to the retention periods even after termination over 11 or even 35 years, Swisscom or a designated successor must establish an archiving system for this, so that this information can also be used in legal negotiations. The identifications provided can no longer be used with a possible successor, i.e. new registrations are necessary in this case.

Electronic signatures may be presented as evidence in litigation. As a rule, with the exception of the qualified signature, they are subject to the free assessment of evidence. Since “simple” and “advanced” electronic signatures are hardly or only roughly defined by law, it is the court’s responsibility to accept such a signature or not. The party wishing to present these signatures as valid must provide the relevant evidence. In the case of Swisscom, it is helpful that the advanced signatures are also subject to a very strict audit according to the ETSI standard for “NCP+” signatures and thus such audit reports can be used. In the case of a qualified signature, the reversal of evidence shall apply. Since the qualified signature is precisely determined by law and, for example, both Switzerland and Austria offer validators for the validity of such signatures on the web, these signatures are considered valid until a party proves otherwise and thus also proves that the supervisory authority or OFCOM as well as the auditors have not complied with their obligations. After 11 years in Switzerland or 35 years in Austria, proof can also cause difficulties in the qualified field, as the documents for registration have to be destroyed. Nevertheless, the signature is still visible as “qualified”.

In the context of an evidence after many years, it should also be noted that electronically archived documents should be repeatedly time-stamped from time to time. It may happen that algorithms are no longer as robust. A timestamp seals the document with the latest algorithms, protecting the integrity of the document, including signatures.

Qualified eIDAS signatures are only considered “qualified” in the EU (and EEA) area, and ZertES/SigE signatures are also considered qualified only in the Swiss jurisdiction. This means that when a third state chooses the law, these signatures can no longer achieve their “qualified” effect or, if necessary, become. not even recognised.

Switzerland (QES), ZertES:

The CP/CPS provides that the identification and the stored documentation can be used for a maximum of 5 years, shorter if the validity period of the presented ID card/passport ends before the five-year period or if the identification procedure on the part of the auditor does not allow 5 years.

The retention period in accordance with Article 11.1 of the Ordinance of SigE/ZertES (activity journal) applies: “The recognised providers shall keep the registrations relating to their activities and the supporting documents relating to them for eleven years.” Swisscom also understands this period as a retention period for the documents submitted in the ID process, in particular a copy of the ID.

1 year reserve was added as a “safety buffer” in order to avoid Swisscom RA agencies being able to calculate the 11 years differently, which would mean that Swisscom would no longer have documentation in specific cases, especially in the application of Article 17 of the SigE/ZertES (Unlimited Liability).

  • As a summary the archival time is 17 years, which are also disclosed in the terms of use.

Europe, (QES), eIDAS:

This is the same justification and derivation as in the case of QES in Switzerland only with the difference that in Austria the legal retention period is 30 years.  Article 10.1 of the SVG (Signature and Trust Services Act) provides:

Access rights and retention period

10. (1) At the request of courts or other authorities, a qualified TSP shall grant access to the documentation in accordance with Article 24(2) lit. h eIDAS-VO and its certificate database.

(2) […].

(3) The documentation is provided by the qualified TSP for 30 years, calculated from the date qualified certificate entered at the end of the validity or, in the absence of such, 30 years from the date on which relevant information on the data issued and received by the qualified VDA in the course of its activities is incurred.

  • As a summary the archival time is 36 years, which are also disclosed in the eIDAS Terms of Use.

Advanced Signatures (eIDAS, ZertES)

The CP/CPS provides that the identification and the archived documentation can be used for a maximum of 5 years, shorter if the validity period of the submitted card ends before the five-year period or if the identification procedure does not allow 5 years.

There are no legal retention periods in the area of AES, as the retention periods are not regulated by law. However, the ETSI standards provide for a period of 7 years. This information is derived from ETSI Directive EN 319 411-01:

6.4.6 Records archival

The following particular requirements apply:

NOTE: ETSI TS 101 533-1 [i.13] suggests provisions on how to preserve digital data objects.

a) The TSP shall retain the following for at least seven years after any certificate based on these records ceases to be valid:
i) log of all events relating to the life cycle of keys managed by the CA, including any subject key pairs

generated by the CA (see clause 6.4.5, item g));

ii) documentation as identified in clause 6.3.4.

1 year reserve was added as a “safety buffer” in order to avoid that Swisscom RA agencies could calculate the 11 years differently.

  • As a summary the archival time is 13 years, which are also disclosed in the eIDAS Terms of Use.

In the case of personal certificates, Swisscom only issues short-term certificates (so-called “one-shot” certificates) that have a lifetime of 10 minutes and are only used for one signature request. The probability that the certificate was compromised during these 10 minutes is practically non-existent. After that the certificate is invalid and cannot be compromised. Thanks to the long-term validation, the signatures with this certificate remain valid and can also be validated for periods of time after expiry.

If the entire CA (i.e. the root certificate) of the certification and trust service has been compromised, there is a process that Swisscom describes in its CP/CPS (see Downloads Area – Repository).

If a signatory loses his authentication medium or discovers that his identity has been determined incorrectly, our support team must be informed immediately. In a contractual relationship with one of our partners, please contact the partner with whom you have provided your signature or identification. He will then take further steps to block this identification. If a seal certificate has been compromised, please use the contact details provided at

  1. Contract orally closed: Very difficult to proof (only with witness of other persons)
  2. Signed by simple signature, e.g. a scanned signature image: Same problem. The process of generation of this signature must be analysed in court and due to the weakness of the procedure witness of other persons or other hints will play a major rule to proof the power of attorney.
  3. AES: for verification of a valid signature the parties have again to go to court. The court will ask a specialist to investigate the advanced electronic signature of Swisscom. Due to the audits Swisscom performed the specialist can benefit from it. Nevertheless the AES is more weak as the QES e.g. concerning the way to identify/register persons, the time of archival (only 7 years), and the 1 factor authentication for the signature in contrast to a 2-factor authentication (thus a stolen mobile smartphone could be used for a signature)
  4. QES: the verification of a valid signature can be done directly via or have not to go to court in case of doubt. Only if somebody doubts generally the audited trust service and this will be a hard proof …. QES signature evidences and logs will be stored as long as foreseen for all commercial and tax documents in the business record: more than 10 years in Switzerland and 35 years in the EU.

Due to the GDPR regulations and the fact that subsidiaries are not automatically part of any data processing agreement we need to sign with each subsidiary an extra RA Agency contract.

We recommend the use of the PAdES LTA standard (see ETSI TS 103 172) for purpose of longterm validation. Please find more hints here: . PDFs should be in compliance with the PDF/A standard.

In the case of a remote signature, Swisscom manages your keys for the signature certificates in trust. With a personal signature, the signature certificates are only generated for the signature and lose their validity after approx. 10 minutes. Hereby we avoid the notification of a compromise of the certificate by the signatory, i.e. a certificate cannot be compromised. The procedure has several advantages:

The end user does not need to contact Swisscom (e.g. a user account to revoke certificates).

The recipients of signed documents do not have to deal with revocation lists and OCSP (online certificate validity check).

Security problems with applications that only rely on regular revocation list updates are avoided.

OCSP queries lead to time delays for the recipient.

In addition, a short-term certificate always provides a positive response – an OCSP query can only ever provide a negative response.


Important, the signature that was made with the QES is of course still valid, regardless of the certificate.


The short-term certificates are issued based on registrations of the registration service, i.e. they are based on strong authentication. A short-term certificate is only generated if there is authentication (release) in the 2FA procedure.

Example for analogy in the paper environment: I sign a contract with an ink pen. The ink in the pen is empty after the signature. The contract remains valid, of course.


When signing with a QES, the following evidence archival periods apply:

The retention periods for the identification evidence and the activity journal for EU signatures in Austria (where we are accredited) are 35 years and 10 years in Switzerland.

Due to the PAdES B LTA standard, signatures can also be validated a long time after expiry on the basis of short-term certificates.

The algorithms for hashing (checksum formation) and encryption of the hash follow the recommendations of the ETSI standard ETSI TS 119 312, which in turn also follow the NIS standards. These algorithms have certain assumptions about periods of 1->6 years in which they are stable. However, developments (e.g. cracking of algorithms) can also quickly lead to changes here. Swisscom Trust Services, for example, is now changing its root CA again to comply with the requirements > 6 years. A new edition of the specification is expected again this autumn.

For long-term validation, it is therefore necessary to regularly ensure integrity on the basis of the latest algorithms, e.g. annual time stamping of all documents or use of appropriate archiving solutions. Keyword “preservation of evidentiary value” – see DIN 31647:2015-05.

According to the eIDAS regulation, TSPs must be accredited nationally and follow the national laws, rules, and regulations given by the national Supervisory Body as far as no other EU-wide regulation has set out some rules, like the implementing decisions of the EU commission, e.g., for the ADES standards or the security levels of the eID or some rules from the eIDAS regulation itself. By this, every country has different national standards for their TSPs; for example, in Germany, the BSI must approve some aspects, or in France, the institute ANSII. In some countries, e.g., video identification is fully allowed. In others forbidden, and in third countries, only permitted with short-term certificates.

But the EU regulation eIDAS foresees that all qualified electronic signatures from any nationally accredited TSP in any EU country must be accepted by all EU members. Thus, a TSP accredited in France may sell their QES based on the French rules and regulations in Germany, and an Austrian TSP, such as Swisscom, has only to follow up the Austrian rules and regulations and may sell their qualified signatures in other EU countries. The EU trusted list is the standard anchor and confirms that a qualified signature issued by one of the TSPs listed there must be accepted.

With version 2 of the eIDAS regulations, the EU countries will try to harmonize more and more the parts of accreditation, e.g., the way to be registered for a service, and they even want to create an EU e-Wallet as a base for future identification for any trusted service.

You did not find your answer, get in touch with our support.

Support Form
Were we able to help you?

We are glad that we could help you.

It is a pity that we have not yet been able to provide you with the answer you need. Our support team will be happy to help you.