REG. VTS-007 CASE WATCH · EDITION 1 · LESSON SINGAPORE · PDPA 2026
Blog / PDPC Case Watch / Edition 1 / Case 2
Edition 1 · Case 2 of 3 · Full lesson

The test VPN account nobody looked after

A VPN account used to test access to live systems was compromised. PDPC issued directions and no financial penalty.

What happened

Cortina Watch is mainly involved in the retail, import and export of timepieces, branded pens and luxury accessories. On 5 June 2023 it notified PDPC of a ransomware attack on its server.

Personal data of 3,953 individuals was accessed and exfiltrated. For most of them it was a name with a contact number (1,380 people), an address (930), an email address (688) or a date of birth (645). For 234 people it included an NRIC or passport number, and for 8 it included a bank account number.

Cortina Watch had faced multiple brute-force attacks between 30 April and 4 June 2023. On 27 May 2023, a VPN account it had been using to test VPN access to its live environments was compromised. The attacker reached a password-protected master password file, then moved across the servers, copied 5.82 GB of data and deployed LockBit 3.0 ransomware to encrypt other files. The personal data was later posted on the dark web.

What PDPC found

Cortina Watch asked for the case to be handled under PDPC's expedited breach decision procedure, and admitted the facts and a breach of the Protection Obligation. It admitted there had been a lack of "housekeeping" on its test VPN user accounts, and that it had failed to put reasonable access controls on its network through those accounts.

PDPC set out what a security assessment could have led it to adopt:

  • Rules against easy-to-guess usernames. Default names such as "Administrator" and "Guest" were in use on its systems.
  • Multi-factor authentication for all VPN accounts, firewall access and files holding passwords. Cortina Watch admitted it could have done this and had neglected to.

PDPC also found it in breach for not enforcing a robust password policy. Its policy required a minimum of eight characters. PDPC's Guide to Data Protection Practices for ICT Systems encourages a minimum of 12 characters with a mix of upper case, lower case, numbers and special characters, and a limit on failed logins. PDPC pointed to its earlier Lovebonito decision of 19 May 2022, which had treated multi-factor authentication as a baseline requirement for administrative accounts on systems holding sensitive or large volumes of personal data, and expected remote access by privileged accounts to be secured in the same way.

Having considered the impact, Cortina Watch's prompt remediation and its cooperation, PDPC chose not to impose a financial penalty. It directed Cortina Watch to engage a third-party cybersecurity vendor to carry out a targeted security audit to strengthen access control, within 60 days, and to send PDPC a report within 7 days of finishing. Among its own remedial steps, Cortina Watch had taken its servers offline, added certificate-based authentication and two-factor authentication to VPN access, replaced servers running legacy Windows Server 2008 R2, and introduced account lockout after three failed attempts.

Our view, not PDPC's

Everything below is Veritos advice for your business. It is not something PDPC decided.

Where it goes wrong in practice

Test accounts are created to get something working, usually in a hurry and with a simple name and password. Then the project ends. The account stays, because nobody was assigned to remove it, and the person who made it has moved on or forgotten.

From the outside, a test account is an ordinary way in. Attackers don't care why it exists. If the password is short and nothing else is checked at login, repeated guessing is enough. A single file holding other passwords then turns one weak account into access to everything.

The absence of a fine did not mean no consequence. Cortina Watch still had to commission an independent audit and report the results to PDPC.

Lessons learned

  • Temporary and test accounts are real accounts, with the same exposure as any other.
  • Remote access is where multi-factor authentication matters most.
  • A password policy that is written down but not enforced doesn't protect anything.
  • Accounts need an owner and a review date, or they don't get reviewed.

How to avoid it

  • List every account that can reach your network remotely, including VPN, firewall and administrator accounts, and name an owner for each.
  • Remove or disable test, temporary and default accounts as soon as the work they were created for is finished.
  • Turn on multi-factor authentication for VPN, firewall access and any file or system that stores passwords.
  • Set a password rule you can enforce in the system, such as 12 characters with a mix, and lock accounts after a few failed attempts.
  • Review the account list every quarter, and whenever a staff member or vendor leaves.
Questions to ask your team
  • Who could tell us today, from a single list, every account that can log in from outside the office?
  • Do we still have any account named "test", "admin" or "guest"?
  • If one account were compromised, would the attacker find a single file or system that opens the rest?

If you're not sure who currently owns your accounts and access reviews, talk to us. It is the kind of routine we help organisations keep in place, so it doesn't depend on one person remembering.