Identity Access Management

Principal workflows

• Assess and design: Moraph starts from your risk assessment and the FFIEC guidance to agree which users, applications and access paths need which authentication strength, and records each decision in a configuration baseline your institution approves.
• Implement: Moraph builds the Okta tenant to the approved baseline: directory integration, single sign-on for each application, authentication policies, MFA enrollment and automated provisioning where the application supports it.
• Operate: Moraph runs the tenant day to day: change requests, application onboarding, monitoring of Okta's System Log for suspicious sign-in activity, and escalation to your team when a decision is yours.
• Review and evidence: Access reviews, policy exception reviews and a regular service review keep the configuration tied to your risk assessment, and the evidence is kept for internal audit and examiners.

Who uses it

• CISOs and information security officers at banks, credit unions and other financial institutions
• IT and infrastructure teams who run identity without a dedicated identity engineering group
• Risk and compliance staff who map controls to the FFIEC guidance and the institution's risk assessment
• Application owners who need their systems behind single sign-on and automated provisioning
• Internal audit and examiners, who need evidence of access controls and reviews

Reporting

• MFA coverage by user group and authenticator type
• Applications behind single sign-on and those still outside it
• Open exceptions and their review dates
• Access review results and removals carried out
• Configuration changes with requester and approver
• Escalated identity events and decisions

Features

• Risk-based configuration baseline: A written baseline that ties each application and user group to an authentication requirement and to the part of your risk assessment it answers.
• Single sign-on: Okta provides single sign-on to cloud and on-premises applications using SAML and OpenID Connect, so staff use one strong sign-in instead of separate passwords.
• Multi-factor authentication: Okta enforces MFA with the authenticators you approve, such as Okta Verify push and FIDO2 security keys, with phishing-resistant options for administrators and higher-risk access.
• Authentication policies: Okta evaluates each sign-in against policy rules for the user group, application, network location and device, and asks for stronger authentication or denies access as configured.
• Joiner, mover and leaver automation: Okta creates, changes and deactivates accounts in connected applications from your HR system or directory, so a leaver loses access everywhere that is connected at once.
• Privileged and third-party access: Separate policies for administrators, contractors and vendors, with stronger authentication and access limited to what each group needs.
• MFA exception register: Every exception to the baseline is recorded with its owner, reason, compensating control and review date, and reported until it is closed.
• Sign-in monitoring: Moraph monitors Okta's System Log for patterns such as repeated MFA denials, sign-ins from unexpected locations and administrator changes, and escalates them to your team.
• Access reviews: Periodic reviews where application owners confirm or remove each user's access, using Okta Identity Governance where licensed, with the outcome kept as evidence.
• Managed change control: Every configuration change goes through a request, an approval by your named approver, a test where possible and a record of what was changed and why.
• Application onboarding: New applications are connected to single sign-on and provisioning by Moraph engineers, following the baseline for that application's risk level.
• Examiner evidence pack: On request, a pack showing the baseline, policy settings, MFA coverage, exceptions, access reviews and change history for the period under review.

Integrations

• Active Directory and LDAP: Okta's directory agents connect to your on-premises directory so existing accounts and groups are used for sign-in and assignment.
• HR system: Where supported, your HR system becomes the source of identity, so hires, role changes and leavers drive account changes in Okta.
• Cloud and SaaS applications: Applications are connected by SAML or OpenID Connect for sign-in, and by SCIM or Okta's provisioning connectors where the application supports them.
• Core banking and on-premises applications: Applications that cannot use modern sign-in standards are assessed with you; options include Okta's access gateway or agents where licensed, or a recorded exception.
• Security monitoring (SIEM): Okta's System Log can be streamed to your SIEM or managed detection provider, alongside Moraph's own monitoring.
• Endpoint and device management: Device signals from your endpoint management tool, such as Microsoft Intune, can be used in Okta policies where the integration is licensed.
• Moraph service portal: Change requests, approvals, exceptions, tickets and service reports are kept in Moraph's service portal, which your staff sign in to through Okta.

Deployment

• 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.

Security and privacy

• 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.

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.

Next steps

Book a demonstration or a technical briefing at www.moraph.com/solutions/identity-access-management. Purchasing routes and company information: www.moraph.com/how-to-buy.