MAS Notice on Cyber Hygiene Requirements

Contents

Background

MAS first consulted the industry on the Notice on Cyber Hygiene in 2018. In its 2019 response paper, MAS explained that selected cybersecurity practices from the Technology Risk Management Guidelines were being elevated into legally binding requirements because cyber threats remain persistent and relevant to all financial institutions.

This is an important point. MAS was not creating a new security concept. It was making selected baseline controls enforceable.

What FSM-N06 Requires for Banks

1. Administrative Accounts

FSM-N06 defines an administrative account as a user account with full privileges and unrestricted access to an operating system, database, application, security appliance, or network device.

Banks must secure these accounts to prevent unauthorised access to or use of such accounts.

This is a privileged access control requirement. In practice, banks should have controls such as privileged access management, least privilege, access review, session monitoring, strong authentication, and proper joiner-mover-leaver processes.

The 2019 MAS response clarified that non-user or non-interactive service accounts were excluded from the administrative account definition.

That is a regulatory scope point, not a security comfort point. Service accounts still need governance because they are often long-lived, overprivileged, and heavily used in lateral movement.

2. Security Patches

Banks must apply security patches to address vulnerabilities across every system. The timeframe must be proportionate to the risk posed by each vulnerability.

This supports risk-based patching.

A critical vulnerability on an internet-facing or critical system should be handled faster than a lower-risk vulnerability on an isolated system. But “risk-based” does not mean open-ended delay.

Where no patch is available, the bank must implement controls to reduce the risk. Useful evidence includes the affected system, vulnerability severity, exposure, patch decision, compensating control, target date, and risk acceptance.

3. Security Standards

Banks must maintain a written set of security standards for every system. Every system must conform to those standards. Where a system cannot conform, the bank must implement controls to reduce the risk.

This is a hardening requirement.

The 2019 response clarified that security standards refer to technical configuration standards. MAS also stated that relevant entities may refer to recognised practices such as CIS and NIST when forming security configuration standards.

The practical challenge is not writing the standard. The challenge is proving that systems follow it. Banks need secure build baselines, configuration checks, exception handling, and periodic review.

4. Network Perimeter Defence

Banks must implement controls at the network perimeter to restrict unauthorised network traffic. The Notice does not prescribe a specific firewall product or design.

Depending on the environment, this may include firewalls, cloud security groups, network ACLs, web application firewalls, API gateways, segmentation controls, or secure ingress and egress filtering.

MAS also clarified in 2019 that network intrusion detection capability and internet surfing separation were not requirements under this specific Notice. That does not mean they are unnecessary. It only means they are outside this legal baseline.

5. Malware protection

Banks must implement one or more malware protection measures on every system, where such measures are available and can be implemented.

MAS changed the wording from “anti-virus” to “malware protection” after industry feedback. That change is sensible. Modern malware protection may include anti-malware, EDR, server workload protection, behaviour-based detection, application control, email security, web filtering, or runtime protection.

If malware protection cannot be implemented on a platform, the bank should still assess the risk and apply suitable alternative controls.

6. Multi-factor Authentication

Banks must implement MFA for:

Administrative accounts on critical systems.
Accounts on systems used by the bank to access customer information through the internet.

FSM-N06 defines a critical system as a system whose failure would significantly disrupt the bank’s operations or materially affect customer service, such as systems that process time-critical transactions or provide essential customer services.

This makes critical system classification important. If the critical system inventory is wrong, the MFA scope will also be wrong. To secure these access paths, utilize strong multi-factor authentication protocols like OIDC or SAML integrated with a trusted identity provider.

The 2019 MAS response also clarified that a central password vault alone does not satisfy MFA if access to the critical system still depends on only one factor. A password vault may improve password management, but it is not automatically MFA.

Third-Party Systems

FSM-N06 includes a limited carve-out. A bank need not comply with a requirement only where it cannot exercise direct control, cannot exercise indirect control through the provider, and it is not reasonable to procure an alternative provider that allows such control.

This is not a blanket exemption for SaaS, outsourcing, intragroup platforms, or managed services.

The earlier MAS response made clear that third-party systems can still be treated as within the entity’s control where the entity can impose contractual requirements on the provider. Review these arrangements as part of standard TPRM vendor evidence audits to establish operational assurance.

The practical sequence is:

Control it directly where possible.
Control it contractually where direct control is not possible.
Assess whether an alternative provider is reasonable.
Use the carve-out only where all conditions are met.

Key Takeaways

Notice scope is broad: FSM-N06 defines “system” as any hardware or software used by the bank. This makes asset inventory and system ownership critical.
Outcome-based wording: MAS does not mandate specific tools, products, or fixed patch timelines. This gives flexibility, but it also requires evidence.
Risk-based is not optional compliance: If a bank cannot patch, cannot conform to a standard, or cannot implement malware protection, it needs documented risk assessment and compensating controls.
Accountability for third-party systems: Outsourcing does not remove accountability where the bank can impose control through contract or provider selection.
Baseline focus: This Notice is not a full cybersecurity programme. It does not fully cover logging, monitoring, penetration testing, secure software development, encryption, API security, SaaS posture management, cloud configuration, service account governance, or incident response. These areas must be addressed through MAS TRM Guidelines, internal standards, architecture review, threat modelling, and operational security controls.

Final View

MAS cyber hygiene notices set a mandatory baseline across regulated financial sectors. For banks, FSM-N06 makes basic controls legally enforceable.

The Notice is not difficult to understand. The hard part is proving consistent implementation across real banking environments: legacy systems, cloud platforms, SaaS, outsourced services, privileged access paths, and exceptions.

The right question is not whether the bank has a policy. The right question is whether the bank can prove that these controls are implemented, working, reviewed, and consistently applied across all relevant systems.

That is where compliance becomes security.