last sync: 2024-Oct-04 17:51:30 UTC

Accounts with write permissions on Azure resources should be MFA enabled

Azure BuiltIn Policy definition

Source Azure Portal
Display name Accounts with write permissions on Azure resources should be MFA enabled
Id 931e118d-50a1-4457-a5e4-78550e086c52
Version 1.0.0
Details on versioning
Versioning Versions supported for Versioning: 1
1.0.0
Built-in Versioning [Preview]
Category Security Center
Microsoft Learn
Description Multi-Factor Authentication (MFA) should be enabled for all subscription accounts with write privileges to prevent a breach of accounts or resources.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
AuditIfNotExists
Allowed
AuditIfNotExists, Disabled
RBAC role(s) none
Rule aliases THEN-ExistenceCondition (1)
Alias Namespace ResourceType Path PathIsDefault DefaultPath Modifiable
Microsoft.Security/assessments/status.code Microsoft.Security assessments properties.status.code True False
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 77 compliance controls are associated with this Policy definition 'Accounts with write permissions on Azure resources should be MFA enabled' (931e118d-50a1-4457-a5e4-78550e086c52)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
AU_ISM 1173 AU_ISM_1173 AU ISM 1173 Guidelines for System Hardening - Authentication hardening Multi-factor authentication - 1173 n/a Multi-factor authentication is used to authenticate all privileged users and any other positions of trust. link 2
AU_ISM 1384 AU_ISM_1384 AU ISM 1384 Guidelines for System Hardening - Authentication hardening Multi-factor authentication - 1384 n/a Multi-factor authentication is used to authenticate privileged users each time they perform privileged actions. link 3
AU_ISM 414 AU_ISM_414 AU ISM 414 Guidelines for Personnel Security - Access to systems and their resources User identification - 414 n/a Personnel granted access to a system and its resources are uniquely identifiable. link 3
Azure_Security_Benchmark_v1.0 3.5 Azure_Security_Benchmark_v1.0_3.5 Azure Security Benchmark 3.5 Identity and Access Control Use multi-factor authentication for all Microsoft Entra ID based access Customer Enable Microsoft Entra MFA and follow Azure Security Center Identity and Access Management recommendations. How to enable MFA in Azure: https://docs.microsoft.com/azure/active-directory/authentication/howto-mfa-getstarted How to monitor identity and access within Azure Security Center: https://docs.microsoft.com/azure/security-center/security-center-identity-access n/a link 3
Azure_Security_Benchmark_v2.0 IM-4 Azure_Security_Benchmark_v2.0_IM-4 Azure Security Benchmark IM-4 Identity Management Use strong authentication controls for all Microsoft Entra ID based access Customer Microsoft Entra ID supports strong authentication controls through multi-factor authentication (MFA) and strong passwordless methods. - Multi-factor authentication: Enable Microsoft Entra MFA and follow Azure Security Center identity and access management recommendations for your MFA setup. MFA can be enforced on all users, select users, or at the per-user level based on sign-in conditions and risk factors. - Passwordless authentication: Three passwordless authentication options are available: Windows Hello for Business, Microsoft Authenticator app, and on-premises authentication methods such as smart cards. For administrator and privileged users, ensure the highest level of the strong authentication method is used, followed by rolling out the appropriate strong authentication policy to other users. If legacy password-based authentication is still used for Microsoft Entra ID authentication, please be aware that cloud-only accounts (user accounts created directly in Azure) have a default baseline password policy. And hybrid accounts (user accounts that come from on-premises Active Directory) follow the on-premises password policies. When using password-based authentication, Microsoft Entra ID provides a password protection capability that prevents users from setting passwords that are easy to guess. Microsoft provides a global list of banned passwords that is updated based on telemetry, and customers can augment the list based on their needs (e.g. branding, cultural references, etc.). This password protection can be used for cloud-only and hybrid accounts. Note: Authentication based on password credentials alone is susceptible to popular attack methods. For higher security, use strong authentication such as MFA and a strong password policy. For third-party applications and marketplace services that may have default passwords, you should change them during initial service setup. How to enable MFA in Azure: https://docs.microsoft.com/azure/active-directory/authentication/howto-mfa-getstarted Introduction to passwordless authentication options for Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/authentication/concept-authentication-passwordless Microsoft Entra ID default password policy: https://docs.microsoft.com/azure/active-directory/authentication/concept-sspr-policy#password-policies-that-only-apply-to-cloud-user-accounts Eliminate bad passwords using Microsoft Entra Password Protection: https://docs.microsoft.com/azure/active-directory/authentication/concept-password-ban-bad n/a link 3
Azure_Security_Benchmark_v3.0 IM-6 Azure_Security_Benchmark_v3.0_IM-6 Microsoft cloud security benchmark IM-6 Identity Management Use strong authentication controls Shared **Security Principle:** Enforce strong authentication controls (strong passwordless authentication or multi-factor authentication) with your centralized identity and authentication management system for all access to resources. Authentication based on password credentials alone is considered legacy, as it is insecure and does not stand up to popular attack methods. When deploying strong authentication, configure administrators and privileged users first, to ensure the highest level of the strong authentication method, quickly followed by rolling out the appropriate strong authentication policy to all users. Note: If legacy password-based authentication is required for legacy applications and scenarios, ensure password security best practices such as complexity requirements, are followed. **Azure Guidance:** Microsoft Entra ID supports strong authentication controls through passwordless methods and multi-factor authentication (MFA). - Passwordless authentication: Use passwordless authentication as your default authentication method. There are three options available in passwordless authentication: Windows Hello for Business, Microsoft Authenticator app phone sign-in, and FIDO 2Keys. In addition, customers can use on-premises authentication methods such as smart cards. - Multi-factor authentication: Azure MFA can be enforced on all users, select users, or at the per-user level based on sign-in conditions and risk factors. Enable Azure MFA and follow Microsoft Defender for Cloud identity and access management recommendations for your MFA setup. If legacy password-based authentication is still used for Microsoft Entra ID authentication, be aware that cloud-only accounts (user accounts created directly in Azure) have a default baseline password policy. And hybrid accounts (user accounts that come from on-premises Active Directory) follow the on-premises password policies. For third-party applications and services that may have default IDs and passwords, you should disable or change them during initial service setup. **Implementation and additional context:** How to enable MFA in Azure: https://docs.microsoft.com/azure/active-directory/authentication/howto-mfa-getstarted Introduction to passwordless authentication options for Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/authentication/concept-authentication-passwordless Microsoft Entra ID default password policy: https://docs.microsoft.com/azure/active-directory/authentication/concept-sspr-policy#password-policies-that-only-apply-to-cloud-user-accounts Eliminate bad passwords using Microsoft Entra Password Protection: https://docs.microsoft.com/azure/active-directory/authentication/concept-password-ban-bad Block legacy authentication: https://docs.microsoft.com/azure/active-directory/conditional-access/block-legacy-authentication n/a link 4
CCCS IA-2(1) CCCS_IA-2(1) CCCS IA-2(1) Identification and Authentication Identification and Authentication (Organizational Users) | Network Access to Privileged Accounts n/a The information system implements multifactor authentication for network access to privileged accounts. link 2
CIS_Azure_1.1.0 1.1 CIS_Azure_1.1.0_1.1 CIS Microsoft Azure Foundations Benchmark recommendation 1.1 1 Identity and Access Management Ensure that multi-factor authentication is enabled for all privileged users Shared The customer is responsible for implementing this recommendation. Enable multi-factor authentication for all user credentials who have write access to Azure resources. These include roles like - Service Co-Administrators - Subscription Owners - Contributors link 3
CIS_Azure_1.3.0 1.1 CIS_Azure_1.3.0_1.1 CIS Microsoft Azure Foundations Benchmark recommendation 1.1 1 Identity and Access Management Ensure that multi-factor authentication is enabled for all privileged users Shared The customer is responsible for implementing this recommendation. Enable multi-factor authentication for all user credentials who have write access to Azure resources. These include roles like - Service Co-Administrators - Subscription Owners - Contributors link 3
CIS_Azure_1.4.0 1.1 CIS_Azure_1.4.0_1.1 CIS Microsoft Azure Foundations Benchmark recommendation 1.1 1 Identity and Access Management Ensure that 'Multi-Factor Auth Status' is 'Enabled' for all Privileged Users Shared The customer is responsible for implementing this recommendation. Enable multi-factor authentication for all roles, groups, and users that have write access or permissions to Azure resources. These include custom created objects or built-in roles such as; - Service Co-Administrators - Subscription Owners - Contributors link 3
CIS_Azure_2.0.0 1.1.2 CIS_Azure_2.0.0_1.1.2 CIS Microsoft Azure Foundations Benchmark recommendation 1.1.2 1.1 Ensure that 'Multi-Factor Auth Status' is 'Enabled' for all Privileged Users Shared Users would require two forms of authentication before any access is granted. Additional administrative time will be required for managing dual forms of authentication when enabling multi-factor authentication. Enable multi-factor authentication for all roles, groups, and users that have write access or permissions to Azure resources. These include custom created objects or built-in roles such as; - Service Co-Administrators - Subscription Owners - Contributors Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk. link 3
CMMC_2.0_L2 AC.L1-3.1.1 CMMC_2.0_L2_AC.L1-3.1.1 404 not found n/a n/a 57
CMMC_2.0_L2 AC.L1-3.1.2 CMMC_2.0_L2_AC.L1-3.1.2 404 not found n/a n/a 19
CMMC_2.0_L2 IA.L1-3.5.2 CMMC_2.0_L2_IA.L1-3.5.2 404 not found n/a n/a 18
CMMC_2.0_L2 IA.L2-3.5.3 CMMC_2.0_L2_IA.L2-3.5.3 404 not found n/a n/a 3
CMMC_L3 IA.1.077 CMMC_L3_IA.1.077 CMMC L3 IA.1.077 Identification and Authentication Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. link 9
CMMC_L3 IA.3.083 CMMC_L3_IA.3.083 CMMC L3 IA.3.083 Identification and Authentication Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. Shared Microsoft and the customer share responsibilities for implementing this requirement. Multifactor authentication requires the use of two or more different factors to authenticate. The factors are defined as something you know (e.g., password, personal identification number [PIN]); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Multifactor authentication solutions that feature physical authenticators include hardware authenticators providing time-based or challenge-response authenticators and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may also employ authentication mechanisms at the application level, when necessary, to provide increased information security. Access to organizational systems is defined as local access or network access. Local access is any access to organizational systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. The use of encrypted virtual private networks for connections between organization-controlled and non-organization controlled endpoints may be treated as internal networks with regard to protecting the confidentiality of information. link 3
CMMC_L3 IA.3.084 CMMC_L3_IA.3.084 CMMC L3 IA.3.084 Identification and Authentication Employ replay-resistant authentication mechanisms for network access to privileged and nonprivileged accounts. Shared Microsoft and the customer share responsibilities for implementing this requirement. Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges such as time synchronous or challenge-response one-time authenticators. link 8
CMMC_L3 SC.3.190 CMMC_L3_SC.3.190 CMMC L3 SC.3.190 System and Communications Protection Protect the authenticity of communications sessions. Shared Microsoft and the customer share responsibilities for implementing this requirement. Authenticity protection includes protecting against man-in-the-middle attacks, session hijacking, and the insertion of false information into communications sessions. This requirement addresses communications protection at the session versus packet level (e.g., sessions in service-oriented architectures providing web-based services) and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. link 11
FedRAMP_High_R4 AC-3 FedRAMP_High_R4_AC-3 FedRAMP High AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
FedRAMP_High_R4 IA-2 FedRAMP_High_R4_IA-2 FedRAMP High IA-2 Identification And Authentication Identification And Authentication (Organizational Users) Shared n/a The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. link 10
FedRAMP_High_R4 IA-2(1) FedRAMP_High_R4_IA-2(1) FedRAMP High IA-2 (1) Identification And Authentication Network Access To Privileged Accounts Shared n/a The information system implements multifactor authentication for network access to privileged accounts. Supplemental Guidance: Related control: AC-6. link 3
FedRAMP_Moderate_R4 AC-3 FedRAMP_Moderate_R4_AC-3 FedRAMP Moderate AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
FedRAMP_Moderate_R4 IA-2 FedRAMP_Moderate_R4_IA-2 FedRAMP Moderate IA-2 Identification And Authentication Identification And Authentication (Organizational Users) Shared n/a The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. link 10
FedRAMP_Moderate_R4 IA-2(1) FedRAMP_Moderate_R4_IA-2(1) FedRAMP Moderate IA-2 (1) Identification And Authentication Network Access To Privileged Accounts Shared n/a The information system implements multifactor authentication for network access to privileged accounts. Supplemental Guidance: Related control: AC-6. link 3
hipaa 11110.01q1Organizational.6-01.q hipaa-11110.01q1Organizational.6-01.q 11110.01q1Organizational.6 - 01.q User Identification and Authentication Non-organizational users (all information system users other than organizational users, such as patients, customers, contractors, or foreign nationals), or processes acting on behalf of non-organizational users, determined to need access to information residing on the organization's information systems, are uniquely identified and authenticated. Customer n/a Azure personnel have not access or visibility into hosted customer environments, and therefore do not dictate or manage the account provisioning of a customer's users. Therefore, this requirement is not applicable. 1
hipaa 1117.01j1Organizational.23-01.j hipaa-1117.01j1Organizational.23-01.j 1117.01j1Organizational.23 - 01.j User Authentication for External Connections Remote access by vendors and business partners (e.g., for remote maintenance) is disabled/deactivated when not in use. Customer n/a Sample of disabled accounts for third-party service providers. 1
hipaa 1173.01j1Organizational.6-01.j hipaa-1173.01j1Organizational.6-01.j 1173.01j1Organizational.6 - 01.j User Authentication for External Connections If encryption is not used for dial-up connections, the CIO or his/her designated representative provides specific written authorization. Customer n/a Dialup modems and connectivity is not permitted within production data and datacenter hosting environments; thus, the control is not applicable. 1
hipaa 1177.01j2Organizational.6-01.j hipaa-1177.01j2Organizational.6-01.j 1177.01j2Organizational.6 - 01.j User Authentication for External Connections User IDs assigned to vendors are reviewed in accordance with the organization's access review policy, at a minimum annually. Customer n/a Evidence of annual review of vendor accounts (e.g., a sample of User Access Rights (UAR) reviews of vendor accounts). 1
IRS_1075_9.3 .7.2 IRS_1075_9.3.7.2 IRS 1075 9.3.7.2 Identification and Authentication Identification and Authentication (Organizational Users) (IA-2) n/a The information system must: a. Uniquely identify and authenticate agency users (or processes acting on behalf of agency users) b. Implement multi-factor authentication for all remote network access to privileged and non-privileged accounts for information systems that receive, process, store, or transmit FTI. (CE1, CE2) c. Implement multi-factor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access. NIST SP 800-63 allows the use of software tokens. (CE11) link 3
ISO27001-2013 A.9.2.3 ISO27001-2013_A.9.2.3 ISO 27001:2013 A.9.2.3 Access Control Management of privileged access rights Shared n/a The allocation and use of privileged access rights shall be restricted and controlled. link 33
ISO27001-2013 A.9.2.4 ISO27001-2013_A.9.2.4 ISO 27001:2013 A.9.2.4 Access Control Management of secret authentication information of users Shared n/a The allocation of secret authentication information shall be controlled through a formal management process. link 21
ISO27001-2013 A.9.4.2 ISO27001-2013_A.9.4.2 ISO 27001:2013 A.9.4.2 Access Control Secure log-on procedures Shared n/a Where required by the access control policy, access to systems and applications shall be controlled by a secure log-on procedure. link 17
New_Zealand_ISM 23.3.19.C.01 New_Zealand_ISM_23.3.19.C.01 New_Zealand_ISM_23.3.19.C.01 23. Public Cloud Security Identity Management and Access Control - Username and passwords n/a Credentials used to access public cloud services can be reused across cloud service providers 3
NIST_SP_800-171_R2_3 .1.1 NIST_SP_800-171_R2_3.1.1 NIST SP 800-171 R2 3.1.1 Access Control Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). Shared Microsoft and the customer share responsibilities for implementing this requirement. Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement 3.1.2. link 55
NIST_SP_800-171_R2_3 .1.2 NIST_SP_800-171_R2_3.1.2 NIST SP 800-171 R2 3.1.2 Access Control Limit system access to the types of transactions and functions that authorized users are permitted to execute. Shared Microsoft and the customer share responsibilities for implementing this requirement. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). link 31
NIST_SP_800-171_R2_3 .5.2 NIST_SP_800-171_R2_3.5.2 NIST SP 800-171 R2 3.5.2 Identification and Authentication Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. [SP 800-63-3] provides guidance on digital identities. link 24
NIST_SP_800-171_R2_3 .5.3 NIST_SP_800-171_R2_3.5.3 NIST SP 800-171 R2 3.5.3 Identification and Authentication Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts Shared Microsoft and the customer share responsibilities for implementing this requirement. Multifactor authentication requires the use of two or more different factors to authenticate. The factors are defined as something you know (e.g., password, personal identification number [PIN]); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Multifactor authentication solutions that feature physical authenticators include hardware authenticators providing time-based or challenge-response authenticators and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may also employ authentication mechanisms at the application level, when necessary, to provide increased information security. Access to organizational systems is defined as local access or network access. Local access is any access to organizational systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. The use of encrypted virtual private networks for connections between organization-controlled and non-organization controlled endpoints may be treated as internal networks with regard to protecting the confidentiality of information. [SP 800-63-3] provides guidance on digital identities. Multifactor authentication requires two or more different factors to achieve authentication. The factors include: something you know (e.g., password/PIN); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). The requirement for multifactor authentication should not be interpreted as requiring federal Personal Identity Verification (PIV) card or Department of Defense Common Access Card (CAC)-like solutions. A variety of multifactor solutions (including those with replay resistance) using tokens and biometrics are commercially available. Such solutions may employ hard tokens (e.g., smartcards, key fobs, or dongles) or soft tokens to store user credentials. Local access is any access to a system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Network access is any access to a system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). link 5
NIST_SP_800-53_R4 AC-3 NIST_SP_800-53_R4_AC-3 NIST SP 800-53 Rev. 4 AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
NIST_SP_800-53_R4 IA-2 NIST_SP_800-53_R4_IA-2 NIST SP 800-53 Rev. 4 IA-2 Identification And Authentication Identification And Authentication (Organizational Users) Shared n/a The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. link 10
NIST_SP_800-53_R4 IA-2(1) NIST_SP_800-53_R4_IA-2(1) NIST SP 800-53 Rev. 4 IA-2 (1) Identification And Authentication Network Access To Privileged Accounts Shared n/a The information system implements multifactor authentication for network access to privileged accounts. Supplemental Guidance: Related control: AC-6. link 3
NIST_SP_800-53_R5 AC-3 NIST_SP_800-53_R5_AC-3 NIST SP 800-53 Rev. 5 AC-3 Access Control Access Enforcement Shared n/a Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. link 21
NIST_SP_800-53_R5 IA-2 NIST_SP_800-53_R5_IA-2 NIST SP 800-53 Rev. 5 IA-2 Identification and Authentication Identification and Authentication (organizational Users) Shared n/a Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users. link 10
NIST_SP_800-53_R5 IA-2(1) NIST_SP_800-53_R5_IA-2(1) NIST SP 800-53 Rev. 5 IA-2 (1) Identification and Authentication Multi-factor Authentication to Privileged Accounts Shared n/a Implement multi-factor authentication for access to privileged accounts. link 3
NZ_ISM_v3.5 AC-11 NZ_ISM_v3.5_AC-11 NZISM Security Benchmark AC-11 Access Control and Passwords 16.4.30 Privileged Access Management Customer n/a A fundamental part of any security policy is the inclusion of requirements for the treatment of Privileged Accounts. This is most conveniently contained in a Privileged Access Management (PAM) section within the agency???s security policy. A PAM policy is a fundamental component of an agency???s IT Governance. link 7
NZISM_Security_Benchmark_v1.1 AC-11 NZISM_Security_Benchmark_v1.1_AC-11 NZISM Security Benchmark AC-11 Access Control and Passwords 16.4.30 Privileged Access Management Customer Agencies MUST establish a Privileged Access Management (PAM) policy. Within the context of agency operations, the agency’s PAM policy MUST define: a privileged account; and privileged access. Agencies MUST manage Privileged Accounts in accordance with the Agency’s PAM Policy. A fundamental part of any security policy is the inclusion of requirements for the treatment of Privileged Accounts. This is most conveniently contained in a Privileged Access Management (PAM) section within the agency’s security policy. A PAM policy is a fundamental component of an agency’s IT Governance. link 9
op.acc.1 Identification op.acc.1 Identification 404 not found n/a n/a 66
op.acc.2 Access requirements op.acc.2 Access requirements 404 not found n/a n/a 64
op.acc.3 Segregation of functions and tasks op.acc.3 Segregation of functions and tasks 404 not found n/a n/a 43
op.acc.4 Access rights management process op.acc.4 Access rights management process 404 not found n/a n/a 40
op.acc.5 Authentication mechanism (external users) op.acc.5 Authentication mechanism (external users) 404 not found n/a n/a 72
op.acc.6 Authentication mechanism (organization users) op.acc.6 Authentication mechanism (organization users) 404 not found n/a n/a 78
op.exp.10 Cryptographic key protection op.exp.10 Cryptographic key protection 404 not found n/a n/a 53
PCI_DSS_V3.2.1 3.2 PCI_DSS_v3.2.1_3.2 PCI DSS v3.2.1 3.2 Requirement 3 PCI DSS requirement 3.2 customer n/a n/a link 7
PCI_DSS_V3.2.1 7.2.1 PCI_DSS_v3.2.1_7.2.1 PCI DSS v3.2.1 7.2.1 Requirement 7 PCI DSS requirement 7.2.1 customer n/a n/a link 7
PCI_DSS_V3.2.1 8.3.1 PCI_DSS_v3.2.1_8.3.1 PCI DSS v3.2.1 8.3.1 Requirement 8 PCI DSS requirement 8.3.1 shared n/a n/a link 7
PCI_DSS_v4.0 3.3.3 PCI_DSS_v4.0_3.3.3 PCI DSS v4.0 3.3.3 Requirement 03: Protect Stored Account Data Sensitive authentication data (SAD) is not stored after authorization Shared n/a Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured. • Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. link 13
PCI_DSS_v4.0 7.3.1 PCI_DSS_v4.0_7.3.1 PCI DSS v4.0 7.3.1 Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know Access to system components and data is managed via an access control system(s) Shared n/a An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. link 17
PCI_DSS_v4.0 8.4.1 PCI_DSS_v4.0_8.4.1 PCI DSS v4.0 8.4.1 Requirement 08: Identify Users and Authenticate Access to System Components Multi-factor authentication (MFA) is implemented to secure access into the CDE Shared n/a MFA is implemented for all non-console access into the CDE for personnel with administrative access. link 8
RBI_CSF_Banks_v2016 8.1 RBI_CSF_Banks_v2016_8.1 User Access Control / Management User Access Control / Management-8.1 n/a Provide secure access to the bank???s assets/services from within/outside bank???s network by protecting data/information at rest (e.g. using encryption, if supported by the device) and in-transit (e.g. using technologies such as VPN or other secure web protocols, etc.) 10
RBI_CSF_Banks_v2016 9.1 RBI_CSF_Banks_v2016_9.1 Authentication Framework For Customers Authentication Framework For Customers-9.1 n/a Implement authentication framework/mechanism to provide positive identify verification of bank to customers. 4
RBI_CSF_Banks_v2016 9.3 RBI_CSF_Banks_v2016_9.3 Authentication Framework For Customers Authentication Framework For Customers-9.3 n/a Banks should act as the identity provider for identification and authentication of customers for access to partner systems using secure authentication technologies 7
RBI_ITF_NBFC_v2017 3.1.c RBI_ITF_NBFC_v2017_3.1.c RBI IT Framework 3.1.c Information and Cyber Security Role based Access Control-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Role based Access Control ??? Access to information should be based on well-defined user roles (system administrator, user manager, application owner etc.), NBFCs shall avoid dependence on one or few persons for a particular job. There should be clear delegation of authority for right to upgrade/change user profiles and permissions and also key business parameters (eg. interest rates) which should be documented. link 15
RBI_ITF_NBFC_v2017 3.1.f RBI_ITF_NBFC_v2017_3.1.f RBI IT Framework 3.1.f Information and Cyber Security Maker-checker-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Maker-checker is one of the important principles of authorization in the information systems of financial entities. For each transaction, there must be at least two individuals necessary for its completion as this will reduce the risk of error and will ensure reliability of information. link 23
RMiT_v1.0 10.54 RMiT_v1.0_10.54 RMiT 10.54 Access Control Access Control - 10.54 Shared n/a A financial institution must implement an appropriate access controls policy for the identification, authentication and authorisation of users (internal and external users such as third party service providers). This must address both logical and physical technology access controls which are commensurate with the level of risk of unauthorised access to its technology systems. link 17
RMiT_v1.0 10.58 RMiT_v1.0_10.58 RMiT 10.58 Access Control Access Control - 10.58 Shared n/a Authentication methods that depend on more than one factor typically are more difficult to compromise than a single factor system. In view of this, financial institutions are encouraged to properly design and implement (especially in high-risk or 'single sign-on' systems) multi-factor authentication (MFA) that are more reliable and provide stronger fraud deterrents. link 3
SOC_2 CC6.1 SOC_2_CC6.1 SOC 2 Type 2 CC6.1 Logical and Physical Access Controls Logical access security software, infrastructure, and architectures Shared The customer is responsible for implementing this recommendation. The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion: • Identifies and Manages the Inventory of Information Assets — The entity identifies, Page 29 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS inventories, classifies, and manages information assets. • Restricts Logical Access — Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative authorities, mobile devices, output, and offline system components is restricted through the use of access control software and rule sets. • Identifies and Authenticates Users — Persons, infrastructure, and software are identified and authenticated prior to accessing information assets, whether locally or remotely. • Considers Network Segmentation — Network segmentation permits unrelated portions of the entity's information system to be isolated from each other. • Manages Points of Access — Points of access by outside entities and the types of data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified, documented, and managed. • Restricts Access to Information Assets — Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets. • Manages Identification and Authentication — Identification and authentication requirements are established, documented, and managed for individuals and systems accessing entity information, infrastructure, and software. • Manages Credentials for Infrastructure and Software — New internal and external infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point. Credentials are removed and access is disabled when access is no longer required or the infrastructure and software are no longer in use. • Uses Encryption to Protect Data — The entity uses encryption to supplement other measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk. • Protects Encryption Keys — Processes are in place to protect encryption keys during generation, storage, use, and destruction 78
SOC_2 CC6.6 SOC_2_CC6.6 SOC 2 Type 2 CC6.6 Logical and Physical Access Controls Security measures against threats outside system boundaries Shared The customer is responsible for implementing this recommendation. • Restricts Access — The types of activities that can occur through a communication channel (for example, FTP site, router port) are restricted. • Protects Identification and Authentication Credentials — Identification and authentication credentials are protected during transmission outside its system boundaries. • Requires Additional Authentication or Credentials — Additional authentication information or credentials are required when accessing the system from outside its boundaries. • Implements Boundary Protection Systems — Boundary protection systems (for example, firewalls, demilitarized zones, and intrusion detection systems) are implemented to protect external access points from attempts and unauthorized access and are monitored to detect such attempts 40
SWIFT_CSCF_v2021 4.2 SWIFT_CSCF_v2021_4.2 SWIFT CSCF v2021 4.2 Prevent Compromise of Credentials Multi-factor Authentication n/a Prevent that a compromise of a single authentication factor allows access into SWIFT systems or applications, by implementing multi-factor authentication.. link 3
SWIFT_CSCF_v2022 4.2 SWIFT_CSCF_v2022_4.2 SWIFT CSCF v2022 4.2 4. Prevent Compromise of Credentials Prevent that a compromise of a single authentication factor allows access into SWIFT-related systems or applications by implementing multi-factor authentication. Shared n/a Multi-factor authentication is used for interactive user access to SWIFT-related applications and operating system accounts. link 5
U.10.2 - Users U.10.2 - Users 404 not found n/a n/a 25
U.10.3 - Users U.10.3 - Users 404 not found n/a n/a 26
U.10.5 - Competent U.10.5 - Competent 404 not found n/a n/a 24
U.11.1 - Policy U.11.1 - Policy 404 not found n/a n/a 18
U.11.2 - Cryptographic measures U.11.2 - Cryptographic measures 404 not found n/a n/a 18
UK_NCSC_CSP 10 UK_NCSC_CSP_10 UK NCSC CSP 10 Identity and authentication Identity and authentication Shared n/a All access to service interfaces should be constrained to authenticated and authorised individuals. link 25
UK_NCSC_CSP 9.1 UK_NCSC_CSP_9.1 UK NCSC CSP 9.1 Secure user management Authentication of users to management interfaces and support channels Shared n/a In order to maintain a secure service, users need to be properly authenticated before being allowed to perform management activities, report faults or request changes to the service. link 6
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: Azure Security Benchmark v1 42a694ed-f65e-42b2-aa9e-8052e9740a92 Regulatory Compliance Deprecated BuiltIn
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn
[Deprecated]: DoD Impact Level 4 8d792a84-723c-4d92-a3c3-e4ed16a2d133 Regulatory Compliance Deprecated BuiltIn
[Deprecated]: New Zealand ISM Restricted d1a462af-7e6d-4901-98ac-61570b4ed22a Regulatory Compliance Deprecated BuiltIn
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn
[Preview]: Australian Government ISM PROTECTED 27272c0b-c225-4cc3-b8b0-f2534b093077 Regulatory Compliance Preview BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Motion Picture Association of America (MPAA) 92646f03-e39d-47a9-9e24-58d60ef49af8 Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for NBFC 7f89f09c-48c1-f28d-1bd5-84f3fb22f86c Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2020 3e0c67fc-8c7c-406c-89bd-6b6bdc986a22 Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2021 abf84fac-f817-a70c-14b5-47eec767458a Regulatory Compliance Preview BuiltIn
Canada Federal PBMM 4c4a5f27-de81-430b-b4e5-9cbd50595a87 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e Regulatory Compliance GA BuiltIn
CMMC Level 3 b5629c75-5c77-4422-87b9-2509e680f8de Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
IRS1075 September 2016 105e0327-6175-4eb2-9af4-1fba43bdb39d Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
New Zealand ISM 4f5b1359-4f8e-4d7c-9733-ea47fcde891e Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
NL BIO Cloud Theme 6ce73208-883e-490f-a2ac-44aac3b3687f Regulatory Compliance GA BuiltIn
PCI DSS v4 c676748e-3af9-4e22-bc28-50feed564afb Regulatory Compliance GA BuiltIn
PCI v3.2.1:2018 496eeda9-8f2f-4d5e-8dfd-204f0a92ed41 Regulatory Compliance GA BuiltIn
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
Spain ENS 175daf90-21e1-4fec-b745-7b4c909aa94c Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
UK OFFICIAL and UK NHS 3937f550-eedd-4639-9c5e-294358be442e Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-08-09 17:24:03 add 931e118d-50a1-4457-a5e4-78550e086c52
JSON compare n/a
JSON
api-version=2021-06-01
EPAC