Identity Access Management

Moraph resells, implements and runs Okta for banks, credit unions and other financial institutions. We configure single sign-on, multi-factor authentication, authentication policies and user lifecycle to match the FFIEC's guidance on authentication and access, then operate the tenant day to day: changes, monitoring, access reviews and support. Your institution keeps the policy decisions, and every configuration change is recorded with its reason and approver.

The problem it solves

Financial institutions are expected to apply multi-factor authentication or equivalent controls to every user who can reach sensitive systems, including employees, contractors and privileged administrators, and to base those controls on a risk assessment. In practice, identity setups grow application by application: some systems sit behind single sign-on and some do not, MFA exceptions linger, leavers keep accounts in systems that were never connected, and nobody can quickly show an examiner how authentication strength relates to risk. Small IT teams rarely have the time to keep the identity platform tuned as applications, threats and guidance change.

Who it’s for

• 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

1. Assess and designMoraph 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.
2. ImplementMoraph 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.
3. OperateMoraph 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.
4. Review and evidenceAccess 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.

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.

Information security officer

Approves the baseline, policy changes and exceptions, and owns the program

IT administrator

Raises change requests, handles first-line user issues and works with Moraph on application onboarding

Application owner

Decides who should have access to their application and completes access reviews

Moraph identity engineer

Configures and changes the Okta tenant under approved change requests

Moraph service manager

Runs the service review, tracks requests and escalations, and reports on the service

Auditor or examiner (read-only)

Views the baseline, configuration evidence, reviews and change history without changing anything

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.

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.

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.

Discovery

We inventory users, directories, applications and current authentication methods with your IT team, and review your risk assessment and any examination findings on access.

Baseline design

We propose authentication requirements by user group and application risk, referenced to the FFIEC guidance, and agree the baseline and exceptions with your information security officer.

Tenant build

Okta is configured to the baseline: directory integration, administrator roles, authentication policies, authenticators and network zones.

Application onboarding

Applications are connected for single sign-on and provisioning in an agreed order, each tested with the application owner before it goes live.

Enrollment waves

Users enroll in MFA in waves, with communications, help desk scripts and a support plan for each wave agreed with you.

Handover to operations

Change process, approvers, escalation contacts, emergency procedures and reporting are agreed, and the service moves into day-to-day operation.

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

• List your applications and check which ones Okta can bring behind single sign-on and provisioning
• Review a sample configuration baseline and check that each requirement traces back to your risk assessment
• Walk through a change request from request to approval to recorded change
• Ask how a suspicious sign-in would be escalated and who decides what happens next
• Review a sample examiner evidence pack against your last examination's requests
• Confirm the split of responsibilities between Moraph, Okta and your team, including user support