Skip to main content
Header logo

The global provider
of secure financial messaging services

Table of contents

1. TLS 1.0 and TLS 1.1 end of support

1.1 Description

Transport Layer Security (TLS) is the protocol used on the internet today to encrypt end-to-end connections. 

1.2 Disallowing Transport Layer Security (TLS) 1.0 and Transport Layer Security (TLS) 1.1 on SWIFT services and

As of January 1 2019, SWIFT will no longer allow TLS 1.0 and TLS 1.1 on all SWIFT services and Security of customers’ data is important and SWIFT is committed to provide the safest and most reliable method of delivering services. 

1.3 Why are we deprecating TLS 1.0 and 1.1?

TLS 1.0 and TLS 1.1 are considered insecure today and have been replaced with TLS 1.2. Standards bodies such as the Payment Cards Industry Security Standards Council (PCI SSC) and the National Institute of Standards and Technology (NIST) recommend disabling TLS 1.0 and TLS 1.1. TLS 1.2 is supported by all major browsers and SWIFT products. 

Note that SWIFT’s Customer Security Programme (CSP) control 2.2 mandates that all software (including operating systems) and hardware (including network devices) are within the actively supported product lifecycle window of the vendor. 

1.4 How to prepare for TLS 1.2?

1.4.1 Browser based services: (e.g.: SWIFT WebAccess, SWIFT Certificate Center, Alliance Lite2, Sanctions Screening, ...)

If you are using an outdated web browser or your browser is not configured to use TLS 1.2, SWIFT recommends to upgrade your browser to Internet Explorer 11 or change the settings of your web browser to enable TLS 1.2. 

For instructions about how to enable TLS 1.2 on Internet Explorer see TIP 5019758.

1.4.2 Alliance Lite2 Autoclient:

To prevent any service interruption after December 31st 2018, customers not using AutoClient 1.2.2 must upgrade the AutoClient to release 1.3 before 

2. Secure the access to applications

2.1 User-id and password

The main method to protect an account is to use a combination of user-id and password. The strength of this protection will greatly depend on the complexity of the password.

SWIFT recommends that at least these criteria are met:

  • At least 8 characters long
  • Combines digits, special characters, uppercase and lowercase letters
  • Only used for accessing
  • Not trivial (e.g. dictionary words)

Changing your password regularly is another good practice – your administrator may mandate this.

Obviously the complexity of your password is nothing compared to the requirement to keep it secret. The best way to do that is to memorize it and not keeping any written copy.

2.2 2-step verification

2-step verification is a security measure that helps protect your account from unauthorised access if someone manages to obtain your password. An additional layer of security requires a verification code to be entered along with your username and password.

This code can be delivered to you by SMS, voice message, or e-mail. SMS and voice message are the preferred means of delivering the verification code. This is because your e-mail address is already linked to your account and an external means of providing the authentication code is favoured.

Note that the secure channel application on uses a one-time password to secure each transaction that involves sensitive data. Security officers accessing the application must use their personal secure code card to generate the required one-time passwords.

3. Visit only trusted websites

3.1 Check the URL

  • Verify the URL of the web page before entering any personal data such as your e-mail address and password.
  • SWIFT always uses a secure connection to ask for your e-mail address and password. The URLs used by SWIFT start with "" or "".

3.2 Verify the certificate on HTTPS websites

In most browsers this is done by clicking on the lock symbol either at the top or the bottom of the browser window.

3.3 Use a login-seal

You have the ability to define a seal that will be displayed to you every time you access the login page. When you see this login-seal you are sure to be at the right place to enter your credentials. SWIFT recommends using it to improve security.

To learn how to set up a login-seal, please see this page.

4. Use a recent browser

Using a recent browser is the best way to avoid common attacks and keep your account safe. SWIFT strongly encourages you to update it regularly. A recent browser means that you will have access to the latest security standards provided by the vendor. You should also update all the plugins (e.g. Java, Flash) that are integrated within the browser.

5. Phishing & social engineering

5.1 What is phishing?

Phishing is an attempt to get hold of your data with malicious intent, in order to abuse your personal details, such as user-id and password. It is the most common way to do social engineering. In practice it often involves asking you to click on a link to a malicious website that looks like the site of a trusted institution. Phishing can also be performed via phone or chat by people pretending to be a trusted party, such as the helpdesk.

5.2 Secure mailing practices

Mail sender and embedded links can easily be spoofed. Therefore emails sent from SWIFT are generally digitally signed and as a receiver you must verify the signature.

SWIFT will never ask you to change your credentials by email, unless you requested a change yourself.

5.3 How to prevent a phishing attempt?

Verify the signature (see tip 5022540 for a step-by-step guide).

In case our emails contain embedded links, you must check that:

  • The URL (mouse-over the link to see the real URL) starts with one of the below:
  • After you click and are redirected, one of the above domains is still shown in your browser’s address bar,
  • It uses secure HTTPS protocol, and 
  • A valid certificate is assigned to SWIFT’s website.

5.4 Email signature & certificate

We use different systems for email send-out, with different signatures & certificates. 



For example (each address has its own signature): 

Examples Operations
Examples Deployment


These e-mails are signed with certificates issued by Comodo. Your email systems must trust Comodo as a Certification Authority (CA) in order to trust the e-mails signed by Comodo. If not, you may receive a warning or an error.

What if you get an error?

Trust the Comodo root certificate in your email client, and ask your IT/Helpdesk to set trust these at company level. 

Your email client must also have access to the internet in order to download the revocation list (CRL) published by Comodo and/or to allow OCSP validation (Online revocation validation).

If you still face issues after these steps, please contact Customer Support.