Security, data and compliance in Identity Access Management

How Identity Access Management protects data and supports your compliance obligations.

Security controls

Named Moraph administrators

Moraph staff work in your tenant with individual accounts, the least admin rights the service needs and phishing-resistant MFA; there are no shared accounts.

Role-based access

What each person at your institution and at Moraph can see and do follows their role; requesting a change is separate from approving it.

Complete audit trail

Okta's System Log records every sign-in and administrator action, and Moraph's change record links each change to its request and approval.

Encryption and keys

Service records Moraph holds are encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

People decide

Moraph's tooling may suggest how to classify a sign-in event, but an engineer reviews it, and actions affecting your users are decided by your institution or the agreed procedure.

Audited company-wide

Moraph is audited to SOC 2 Type II and ISO/IEC 27001 across the company, including the teams that run this service. Okta's own attestations cover the platform.

Requirements it supports

• FFIEC Authentication and Access to Financial Institution Services and Systems (2021)
• FFIEC IT Examination Handbook, Information Security booklet
• Gramm-Leach-Bliley Act and the Interagency Guidelines Establishing Information Security Standards
• FTC Safeguards Rule (16 CFR Part 314), for non-bank financial institutions
• NYDFS Cybersecurity Regulation (23 NYCRR Part 500), including Section 500.12 on multi-factor authentication
• NIST SP 800-63B Digital Identity Guidelines, used as a reference for authenticator strength

The product supports these requirements; meeting them remains your organization's responsibility.

Where it runs

• Licences through Moraph: Moraph resells the Okta subscription and runs the tenant as one service, subject to Okta's terms.
• Your existing Okta tenant: If you already license Okta, Moraph reviews the current configuration against a new baseline and takes over operation of the tenant.
• Co-managed: Your team keeps some administration, such as first-line support or application onboarding, and Moraph runs the rest; the split is written into the responsibilities for the service.

Limitations

• Moraph is not Okta. Okta operates the platform, and Okta's own service commitments, roadmap, maintenance and outages apply.
• Okta licences are subject to Okta's terms. Some capabilities, such as identity governance or access gateways, need their own licences.
• Moraph configures controls to support the FFIEC guidance, but your institution owns the risk assessment and decides whether the controls are adequate. Moraph does not certify compliance.
• Applications that support neither modern sign-in standards nor an Okta integration cannot be brought behind single sign-on; they are recorded as exceptions with compensating controls.
• Automated deactivation only reaches applications connected for provisioning. Others need a manual leaver step, which the leaver report highlights.
• Moraph's monitoring covers identity events in Okta. It is not a replacement for your institution's wider security monitoring or incident response.
• Customer-facing online banking authentication is usually provided by your digital banking vendor and is outside this service unless agreed separately.
• Moraph does not make policy decisions or accept risk on your behalf; exceptions and escalated events need a decision from your named approver.