What MAS Auditors Look for in Your Identity and Access Architecture
Monetary Authority of Singapore (MAS) examiners assess identity and access against the access control requirements of the MAS Technology Risk Management (TRM) Guidelines, which cover user access management, privileged access management, and remote access. They expect a reconciled account inventory, registers of privileged and service accounts with named owners, no shared privileged logins, MFA on sensitive functions, tamper-protected audit trails, and evidence of periodic access reviews and independent penetration testing.
If your institution is regulated by the Monetary Authority of Singapore, your identity and access controls will be examined at some point. It might happen during a MAS inspection, during your annual audit, or during due diligence after an incident. The Technology Risk Management Guidelines give access control an entire dedicated section, and identity requirements also surface in the parts of the Guidelines covering risk management, data and infrastructure security, cyber security operations, and IT audit. In practice, access control is one of the areas where the gap between “we have a policy” and “we can show it working” is widest.
This guide walks through what examiners actually ask to see, mapped to the requirements in the Guidelines, in roughly the order the requests arrive. None of this requires a specific product. It requires records, and it requires that the records match reality. By the end, you will know which requirements drive which examiner questions, which documents to have ready, which internal checks to run before the examiner runs them for you, and how to sequence the preparation over eight to ten weeks.
Who MAS examines, and the difference between TRM notices and guidelines
The TRM framework applies to financial institutions regulated by MAS: banks, insurers, capital market intermediaries, exchanges, asset managers, payment service providers, and licensed fintechs. MAS first issued technology risk guidance in 2001, in the era of internet banking, and the current TRM Guidelines are the revised version released in January 2021.
Two instruments matter here, and it helps to keep them straight. The TRM Notices are binding regulatory instruments; non-compliance is a regulatory breach, and the Notices include obligations such as reporting relevant incidents to MAS. The TRM Guidelines are supervisory expectations rather than statute. MAS has been clear that it assesses how institutions implement the Guidelines during inspections, and gaps can lead to supervisory action even though the Guidelines themselves are not law. For identity and access purposes, the practical position is simple: treat the Guidelines as the exam syllabus and the Notices as the parts of the syllabus with penalties attached.
One more distinction worth making early is; “MAS auditors” in everyday usage covers two different people: MAS supervisory staff conducting an inspection, and your external or internal auditors assessing TRM alignment. The Guidelines separately expect the institution’s own IT audit function to give the board an independent opinion on technology risk controls, which means access control gets examined from inside as well as outside. All three reviewers ask for largely the same evidence, so the preparation below serves them all.
| Instrument | Status | What it means for IAM |
| TRM Notices | Legally binding | Baseline requirements, including incident reporting to MAS, are mandatory |
| TRM Guidelines (Jan 2021) | Supervisory expectation | Detailed IAM practices MAS assesses during inspection |
| IT audit expectation | Supervisory expectation | Your own audit function must independently assess the same controls |
Where access control sits in the MAS TRM guidelines
The access control section of the Guidelines splits into three parts, and knowing this structure helps, because examiners organise their requests the same way.
- User access management covers the full lifecycle for every account: the principles for granting access, the process for provisioning, changing, and revoking rights, unique identification and logging of user activity, password policy, multi-factor authentication for sensitive functions, periodic access reviews to catch dormant and redundant accounts, prompt revocation when roles change or employment ends, and the requirement that service providers face the same restrictions as staff.
- Privileged access management narrows to accounts that can inflict serious damage: privileged access on a need-to-use basis with logged and reviewed activity, and a managed process for system and service accounts used by applications and databases.
- Remote access management requires encrypted remote connections and strong authentication, such as MFA, for users connecting from outside.
Identity does not stop at access control. The risk management framework in the Guidelines expects identified threats, a maintained risk register, and metrics, all of which examiners expect to include identity risks. The data and infrastructure security requirements bring in lateral movement and network segmentation, where credential misuse is the usual vehicle. The cyber security operations requirements cover log collection, protection, retention, baseline profiling of normal activity, and event correlation, which is where your access logs either prove useful or prove decorative. The IT audit requirements close the loop. A well-prepared institution reads the access question across all of these areas rather than the access control section alone.
The three access control principles: never alone, segregation of duties, least privilege
The guidelines name three principles that should govern how access is granted: never alone, segregation of duties, and least privilege. Almost every question an examiner asks about identity is one of these principles wearing different clothes, so it is worth being precise about what each means.
- Never alone means no single person can perform sensitive system functions end to end without a second party involved. Think production deployments requiring a second approver, or payment file releases needing dual control.
- Segregation of duties means the person who initiates a sensitive action is not the person who approves it, and the person who administers a system is not the person who audits it. Developers with standing write access to production is the classic finding under this principle.
- Least privilege means each identity holds the minimum access its current role requires, granted by role and responsibility rather than by seniority or convenience. Access granted “because they’re a VP” fails this test, and examiners know to look for exactly that pattern.
When you cannot immediately tell which document an examiner wants, translating their question back to one of these three principles usually reveals it.
The account inventory: the first document MAS examiners request
Before anyone looks at a control, they look at the list. Who has access to what, and why. Examiners will typically ask for a current inventory of user accounts on critical systems, mapped to roles and to a business justification. The Guidelines back this directly: they expect periodic user access reviews by appropriate parties, such as information asset owners, specifically to identify dormant accounts, redundant accounts, and inappropriate rights, with exceptions resolved promptly.
The common failure here is staleness. The inventory exists, but it was exported eight months ago for the last audit and nobody has reconciled it since. Leavers still hold accounts. People who changed roles kept the permissions of the old role and gained the permissions of the new one, a pattern sometimes called privilege creep, and the pattern that periodic access review is designed to catch.
If you run one exercise before your next review, run a reconciliation: pull live account lists from your critical systems and compare them line by line against HR records. Every mismatch you find first is one the examiner does not find for you. Institutions that do this quarterly tend to walk into inspections with a short, boring conversation about access inventory. That is the goal.
| Related read: CVE-2026-10753: A Broken Access Control Flaw CredShields Found in Google’s Site Kit, a worked example of how an access control gap looks in the wild. |
Joiners, movers, and leavers: how MAS examiners test the access lifecycle
The Guidelines expect a user access management process to provision, change, and revoke rights, with authorisation from appropriate parties such as the information asset owner. They add that rights no longer needed, because of a transfer or a termination, should be revoked or disabled promptly. Between them, these requirements define the lifecycle examiners probe.
- Joiners. How is access requested and approved for a new hire? The expected answer is a documented request tied to a role, an approval from the system or data owner, and a grant that matches what was approved. Role-based access, where permissions come from a defined role rather than being assembled by hand, makes this dramatically easier to evidence.
- Movers. This is the stage most institutions handle the worst. When someone changes departments, is their old access removed, or merely added to? Examiners ask for a recent example: pick an internal transfer from the last six months and show the before and after. If the after includes everything from the before, you have found your gap before they did. The pattern has a name in identity circles, the ghost admin: someone who left an administrative role but kept its privileges.
- Leavers. How quickly is access revoked after departure, and who confirms it? The strongest evidence is a leaver checklist with timestamps, showing revocation across all critical systems within your defined window. The weakest is an assurance that “IT handles it.” A leaver whose VPN credentials still work three weeks after their last day is the kind of finding that colours an entire inspection.
Privileged access management: the four checks MAS examiners run
The Guidelines set the frame: privileged users can inflict severe damage on the stability and security of the IT environment, so privileged access should be granted on a need-to-use basis and the activity of those accounts logged and reviewed as part of ongoing monitoring. Examiners turn that into four checks.
- The register. You should be able to produce a list of every account with elevated rights on critical systems, who holds it, and what it is for. If the honest answer is “we would have to go and check,” that is the finding.
- Individual accountability. The Guidelines expect user access records to be uniquely identified and logged for audit and investigation. A generic admin login used by three engineers defeats that: no audit trail can attribute an action to a person. The TRM framework’s position against shared privileged accounts follows directly. Where shared accounts are technically unavoidable, examiners expect a vaulting or check-out mechanism that records who used the credential and when, so attribution survives even though the account is shared.
- Approval workflow. How does someone get privileged access, and who signs off? A ticket trail showing request, approval, and grant, with dates, answers this cleanly. Verbal approvals do not. For the most sensitive systems, examiners increasingly expect just-in-time elevation: privileged rights granted for a task and a time window rather than held permanently, which is the strictest reading of need-to-use.
- Review cadence. Privileged access should be recertified on a defined schedule, more frequently than standard access. You should be able to show the last completed cycle: who reviewed, what was revoked, and when. A recertification exercise that has never revoked anything invites the question of whether anyone is really looking.
There is also a Singapore-specific reason this area gets attention. The public Committee of Inquiry report into the 2018 SingHealth breach recommended, among other measures, tighter control and monitoring of administrator accounts. Examiners in this jurisdiction carry that history into the room.
Who counts as a privileged user: a wider net than most teams cast
Most teams answer “privileged user” with “IT administrators” and stop. Examiners cast wider, and the register should too. A privileged user is anyone whose access could cause serious financial, operational, or reputational damage if misused, which in a financial institution includes at least:
- Infrastructure and platform administrators, the obvious case
- Database administrators with direct access to customer or transaction data
- Third-party vendors and contractors performing maintenance or development on production systems
- Finance staff who can initiate or release high-value transactions
- Staff with administrative control over public-facing platforms, since misuse there causes immediate reputational damage
The test is impact, not job title. If your privileged account register contains only the IT department, expect the examiner to ask about everyone else on this list.
Service and system accounts: the access control questions teams prepare for least
The Guidelines address this directly: system and service accounts, used by operating systems, applications, and databases to access other systems’ resources, need a process for managing and monitoring their use for suspicious or unauthorized activity. Human accounts get most of the attention internally, so non-human identities (NHIs) including service accounts, API keys, OAuth tokens, and pipeline credentials are where examiners frequently find soft spots. These identities often hold broad permissions, hardcoded secrets, passwords that never rotate, and no clear human owner.
Be ready to answer three questions about them. Who owns each service account? When were its credentials last rotated? What would break, and who would know, if it were disabled? If your team can answer those for your critical systems, you are ahead of most.
Two practices make this area defensible. First, give every service account a named human owner who is accountable for its scope and its credentials. Second, restrict interactive login on service accounts wherever the platform allows it, so a credential built for machine-to-machine use cannot quietly become someone’s back door. Both are simple to state and both show up clearly in evidence, which is exactly what an examination rewards.
For cloud native and modern environments, examiners expect secrets to be managed via dedicated vaults (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) with short lived tokens and automated rotation, rather than static environment variables or config files.
Passwords, MFA, and remote access under MAS TRM
The Guidelines expect a password policy and a process to enforce strong password controls. The questions here have evolved beyond basic complexity rules, though. Modern examiners evaluate password controls against NIST 800-63B principles focusing on screening for breached/compromised credentials and enforcing MFA over forcing arbitrary 60 day password resets that lead to predictable password patterns.
They also expect multi-factor authentication for users with access to sensitive system functions. Note the scope: sensitive functions, which is broader than “remote users” and broader than “administrators.” For administrative sessions and remote management, examiners increasingly look for phishing resistant MFA (such as FIDO2 WebAuthn keys or PKI-based hardware tokens) to protect against session hijacking and Adversary-in-the-Middle (AiTM) phishing kits. Examiners will want to see where MFA is enforced, and just as importantly, where the exceptions are.
On remote access, the Guidelines expect connections from external networks to be encrypted to prevent eavesdropping, with strong authentication such as MFA for the users making them. If administrators can reach critical systems from outside the corporate network, expect to explain the full path: what gateway, what authentication, what logging, and what happens when a session ends. Remote administrative sessions attract particular attention, since they combine elevated privilege with an off-premises origin.
Audit trails and log protection: where access control meets cyber security operations
Two parts of the Guidelines converge here. The access control requirements expect user access and user management activity to be uniquely identified and logged for audit and investigation. The cyber security operations requirements then expect a process to collect, review, and retain system logs, with the logs protected against unauthorised access, baseline profiles of normal system activity to surface anomalies, and correlation across logs to identify suspicious patterns.
The examiner’s version of all that is evidence integrity. It is one thing to log privileged activity. It is another to show that the logs are complete, retained for the required period, protected from tampering, and actually reviewed. Note the sharpest edge: privileged users should not have access to alter or delete the logs that record their own actions. If your privileged session logs sit locally on the same server the privileged user administers, an examiner will mark a finding. Modern architecture demonstrates log protection through centralized SIEM ingestion and WORM (Write Once, Read Many) immutability storage where sysadmins lack deletion permissions.
The practical test is simple. Pick a privileged action from last month, a firewall change or a production database query, and see whether you can reconstruct who did it, when, under what approval, and from where. If that reconstruction takes your team a day of digging, the architecture has a gap even if every individual control exists. Session recording for privileged access to the most critical systems is becoming a common expectation in this sector; where you have it, be ready to show a sample, and where you do not, be ready to explain what substitutes for it.
Vendor and third-party access under MAS outsourcing expectations
The Guidelines are short and unambiguous in effect on this point: service providers given access to the institution’s information assets should be subject to the same monitoring and access restrictions as the institution’s own personnel. The TRM framework more broadly makes institutions responsible for the technology risk of their outsourced arrangements, and MAS treats cloud services as a form of outsourcing, which pulls your cloud providers’ access model into scope as well.
In practice this means vendors and managed service providers who hold access into your environment should appear in the same inventories, the same reviews, and the same MFA requirements as your own staff. Examiners increasingly ask for the vendor access list specifically, because they know it is the one most likely not to exist. They also ask how vendor access is time-bound: does a support engineer’s access expire with the ticket, or does it persist indefinitely because revoking it is nobody’s job? Contracts matter here too. Your agreements with critical service providers should give you the right to audit their access practices, and examiners may ask to see that clause.
The MAS TRM access control requirement-to-evidence map
Everything above converges on a folder of documents. This table maps each access control requirement to the examiner’s question and the artifact that answers it. It is the single most useful thing to build before a review.
| Requirement area | The examiner’s question | The evidence that answers it |
| Access principles | How do you enforce least privilege and segregation of duties? | Role definitions, SoD matrix for sensitive functions, dual-control configurations |
| Access lifecycle process | Show me how access is granted and revoked | Access request and approval records with asset-owner sign-off |
| Unique identification | Can every action be attributed to a person? | Sample logs showing named accounts, shared-account vaulting records |
| Password controls | What is your password policy and how is it enforced? | Policy plus enforcement configuration, stale-credential reporting |
| Multi-factor authentication | Where is MFA enforced, and where not? | MFA coverage map, phishing-resistant token configuration for admins, documented exceptions with compensating controls |
| Periodic access review | When was access last reviewed, and what changed? | Last completed recertification with revocations listed |
| Prompt revocation | What happens when someone leaves or moves? | Leaver checklists with timestamps, mover before-and-after samples |
| Service provider access | Do vendors face the same controls as staff? | Vendor access list with expiry mechanism, contract audit clauses |
| Privileged access | Who holds elevated rights and who is watching them? | Privileged account register, activity review records |
| Service accounts | How are machine identities governed? | Non-human identity register with named owners, secrets vault rotation policies, and interactive login restrictions |
| Remote access | How do people connect from outside? | Remote access architecture, gateway MFA and encryption configuration |
| Log management | Would your logs survive an investigation? | SIEM retention rules, WORM/immutable storage configuration, log access controls, and activity review records |
None of these documents is exotic. The difficulty is that they must be current, they must agree with each other, and they must agree with the live systems. That agreement is what examiners are really testing.
Penetration testing expectations: independent, regular, and scoped to access control
Documentation shows intent. Testing shows outcome. The Guidelines expect regular vulnerability assessment and independent penetration testing of critical systems, carried out by qualified, independent assessors, with annual testing the widely applied baseline for critical and internet-facing systems. For systemically important institutions, expectations extend further into threat-led penetration testing, where a red team simulates a realistic adversary over an extended engagement.
Access control is one of the areas where testing earns its keep. A well-scoped test will tell you whether the leavers process actually removes access, whether a standard user can reach privileged functions, whether segregation between environments holds, and whether the service account with the never-rotated password can be found and used the way an attacker would find and use it. It also exercises the cyber security operations requirements at the same time: while the testers probe, your monitoring either notices or it does not, and that answer is itself evidence.
A useful sequencing point: run the internal reconciliation and privileged-account review first, then test. Testing an environment you have already tidied gives you findings that matter, rather than a report that repeats what your own review would have caught. The test report then becomes evidence in the map above, and MAS-oriented reviewers give weight to reports carrying a named, accountable assessor rather than an anonymous tool output, for the same reason the Guidelines want actions attributable to people.
Choosing that assessor is its own decision, and the questions worth asking a prospective firm are covered in our guide to what to know before choosing a penetration testing vendor. It is also fair to ask whether the firm holds the assurances it recommends to others; CredShield completed its own SOC 2 Type II audit for that reason.
An 8-to-10-week preparation timeline for a MAS IAM review
If a review is on the calendar, this sequencing has room for the work each stage produces.
- 8 to 10 weeks out: reconcile. Pull live account data from critical systems, reconcile against HR, and close the mismatches. Build or refresh the privileged and service account registers with named owners, using the wider definition of privileged user set out earlier in this guide.
- 6 to 8 weeks out: recertify. Run an access recertification cycle on critical systems, privileged access first. Document what was revoked. Fix the MFA exception list while you are in there.
- 4 to 6 weeks out: test. Commission an independent penetration test scoped to include access control: authentication, authorisation, privilege escalation, and segregation. Independent means external or demonstrably impartial; examiners discount self-assessment, and the IT audit expectations call for the same independence.
- 2 to 4 weeks out: remediate and evidence. Close or formally risk-accept findings, update the remediation tracker, and assemble the evidence folder using the requirement-to-evidence map above.
- Final week: rehearse. Run the reconstruction test on one privileged action end to end. If your team can produce the who, when, why, and from where inside an hour, you are ready.
| Related read: From Vulnerable to SOC 2 Ready: A Complete API Security Overhaul for a Fintech Startup, which follows one fintech through a compliance-readiness sequence like the one above. |
| Final MAS TRM access control checklist before your review |
Frequently Asked Questions (FAQs) about MAS TRM access control
Q1. Are the MAS TRM Guidelines legally binding?
The Guidelines are supervisory expectations rather than statute, but MAS assesses implementation during inspections and can take supervisory action over gaps. The related TRM Notices are binding, including incident reporting obligations. In practice, institutions prepare for both to the same standard.
Q2. What does the MAS TRM access control section cover?
It covers user access management, privileged access management, and remote access management. Identity requirements also appear in the parts of the Guidelines covering risk management, data and infrastructure security, cyber security operations, and IT audit.
Q3. How often should access be recertified under MAS TRM?
MAS does not prescribe a universal interval. Common practice among regulated institutions is at least annual recertification for standard access and more frequent cycles for privileged access, scaled to the criticality of the system.
Q4. Do shared administrator accounts fail a MAS inspection?
A shared privileged account with no attribution mechanism is a likely finding, because the Guidelines expect activity to be uniquely identified and logged. Where sharing is technically unavoidable, a vault or check-out mechanism that records individual usage is the accepted mitigation.
Q5. Does MAS require MFA?
The Guidelines expect multi-factor authentication for users with access to sensitive system functions, and strong authentication such as MFA for remote access. The scope is defined by sensitivity of function, which reaches wider than administrators alone.
Q6. Does MAS require penetration testing of access controls?
The expectation is regular independent penetration testing of critical systems, and access control is a standard part of that scope. Annual testing is the widely applied baseline, with additional testing after significant changes.
Q7. Who should conduct MAS TRM penetration testing?
Qualified, independent assessors. Internal teams testing their own controls do not satisfy the independence expectation, which is why institutions engage external firms and why examiners look for a named, accountable assessor on the report.