Financial Services · Managed platform (Okta)

Identity Access Management

Okta single sign-on and multi-factor authentication, configured for FFIEC guidance and run for you

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

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.

  • Applications outside single sign-on keep their own passwords and their own leaver process
  • MFA exceptions and weaker authenticators remain in place long after they were granted
  • Joiner, mover and leaver changes depend on manual tickets to each application owner
  • Showing examiners how authentication controls follow the risk assessment takes days of gathering

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

Requirements it supports

FFIEC Authentication and Access to Financial Institution Services and Systems (2021)FFIEC IT Examination Handbook, Information Security bookletGramm-Leach-Bliley Act and the Interagency Guidelines Establishing Information Security StandardsFTC Safeguards Rule (16 CFR Part 314), for non-bank financial institutionsNYDFS Cybersecurity Regulation (23 NYCRR Part 500), including Section 500.12 on multi-factor authenticationNIST 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.

Responsibilities

Who is responsible for what

Okta runs the platform, Moraph configures and operates your tenant on it, and your institution owns the policy decisions and its users.

AreaMoraphOktaYour organization
LicensingResells Okta subscriptions, or works with licences you already hold, and tracks usage against themSets the licence terms and the products and features each licence includesAgrees to Okta's terms and decides which products to license
Platform availabilityTracks Okta service notices and tells you when an incident affects youRuns, hosts and maintains the Okta service and its availability commitmentsKeeps a break-glass access plan for critical systems approved by your security officer
ConfigurationDesigns the baseline and builds and maintains the tenant configurationProvides the configuration options the platform supportsApproves the baseline and every change to it
Identity and accessConnects applications and provisioning, and carries out revocations from access reviewsEnforces the configured policies at each sign-inOwns the source of identity, such as HR or directory data, and decides who should have access
MonitoringMonitors the System Log and administrator activity and escalates events that need a decisionRecords sign-in and administrator events and provides built-in threat protectionsDecides on escalated events and runs your wider security monitoring
Incident responseTriages identity events, contains them under the agreed procedure and supports your investigationResponds to incidents in the Okta platform itselfLeads incident response for the institution and makes notification decisions
ChangesApplies approved changes, tests them where possible and records themMakes the platform features available and documents themRequests and approves changes through named approvers
Platform updatesReviews Okta release notes and plans changes that affect your configurationReleases updates to the Okta service on its own scheduleApproves any configuration change needed in response
Policy decisionsRecommends settings with reference to the FFIEC guidance and your risk assessmentNoneOwns the risk assessment and decides authentication requirements and exceptions
User supportSecond-line support for sign-in, enrollment and application access issuesSupport to Moraph for platform defectsFirst-line support for your staff, unless you hand it to Moraph

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of Okta itself, which belongs to its vendor.

  1. Step 1

    The onboarding tracker

    During implementation, every application has a row: its risk level, how it will connect and where it stands.

    ApplicationRisk levelSign-inProvisioningOwner sign-offStatus
    Email and collaborationHighOpenID ConnectSCIMSigned offLive
    Loan origination (example)HighSAMLManualSigned offLive
    HR system (example)HighSAMLSource of identityPendingTesting
    Branch teller platform (example)HighNot supportedManualPendingException proposed
    Expense tool (example)LowSAMLSCIMNot startedPlanned
    During implementation, every application has a row: its risk level, how it will connect and where it stands.

  2. Step 2

    The configuration baseline

    Each user group's authentication requirement is written down, linked to the risk assessment and approved by your security officer.

    Baseline v3 · Example Community Bank (fictional)

    Status
    Awaiting approval
    Prepared by
    Moraph identity engineer
    Approver
    Information security officer
    Changes from v2
    3
    Open exceptions
    2 past review date

    Requirements by group

    • Okta administrators: FIDO2 security key at every sign-in
    • Remote access: Okta Verify with device check
    • Staff on the branch network: Okta Verify push, re-prompt for high-risk applications
    • Contractors: Okta Verify, access limited to assigned applications
    Each user group's authentication requirement is written down, linked to the risk assessment and approved by your security officer.

  3. Step 3

    A change request

    Your team asks, your approver approves, and Moraph applies and records the change.

    CR-1184 · Require security keys for wire room users

    1. Change requested, with reason and affected groupIT administrator
    2. Impact assessed: 14 users, keys to be issued firstMoraph identity engineer
    3. Change approvedInformation security officer
    4. Policy rule tested with pilot usersMoraph identity engineer
    5. Change applied and System Log entry linkedMoraph identity engineer
    6. Change confirmed workingIT administrator
    Your team asks, your approver approves, and Moraph applies and records the change.

  4. Step 4

    Alert triage

    Moraph reviews unusual sign-in activity and escalates what needs your decision, with the evidence and a recommendation.

    User 40317 · Repeated MFA push denials

    Detected from
    Okta System Log
    Pattern
    11 push prompts denied in 20 minutes
    Sign-in location
    Not seen before for this user
    User group
    Operations staff
    Status
    Escalated to your security team

    Recommendation

    • Suspend sessions and reset the password
    • Confirm with the user by a known phone number
    • Consider number matching for this group
    Moraph reviews unusual sign-in activity and escalates what needs your decision, with the evidence and a recommendation.

  5. Step 5

    The access review

    Application owners confirm or remove access, and Moraph carries out and records the removals.

    ApplicationReviewerUsersConfirmedRemovedStatus
    Loan origination (example)Lending operations head62584Complete
    Wire transfer system (example)Payments manager18171Complete
    HR system (example)HR director960Overdue
    Data warehouse (example)Data lead27203In progress
    Application owners confirm or remove access, and Moraph carries out and records the removals.

  6. Step 6

    The monthly service review

    Moraph and your team go through what changed, what happened and what is still open.

    Service review · Sample month

    Changes applied
    7, all approved
    Events escalated
    3
    Users without MFA
    5, all on the exception register
    Applications onboarded
    2
    Open exceptions
    6

    Actions agreed

    • Close two exceptions past their review date or renew them with a reason
    • Onboard the expense tool next
    • Plan for an Okta feature change noted in release notes
    Moraph and your team go through what changed, what happened and what is still open.

Workflows

The principal workflows

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

    • Users, applications and access paths inventoried with your IT and risk teams
    • Each access path rated against your risk assessment
    • Authenticator types and policy rules proposed for each risk level
    • Exceptions listed with an owner, a reason and a review date
    • Baseline approved by your information security officer

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

    • Directory integration with Active Directory or your HR system as the source of identity
    • Applications connected by SAML, OpenID Connect or provisioning connectors
    • Authentication policies and MFA authenticators configured to the baseline
    • Users enrolled in waves, with help desk scripts for each wave
    • Configuration tested against the baseline before each wave goes live

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

    • Change requests raised by your staff and approved by the named approver
    • Changes made in a test tenant or preview first where Okta provides one
    • Sign-in events and administrator activity monitored for patterns that need attention
    • Suspicious activity triaged and escalated to your security team with a recommendation
    • Okta release notes reviewed and relevant changes planned with you

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

    • Access reviews issued to application owners on the schedule you set
    • Revocations from reviews carried out and recorded
    • MFA exceptions reviewed and closed or renewed by your approver
    • Service review covering changes, incidents, coverage and open risks
    • Evidence pack prepared on request for audits and examinations

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Information security officer

CISO, information security officer, ISO, head of IT risk

Owns identity and access policy for the institution and decides how authentication strength follows the risk assessment.

Sees

  • The configuration baseline and its link to the risk assessment
  • MFA coverage, open exceptions and their review dates
  • Escalated security events and Moraph's recommendations
  • Change history, access review results and service reports

Does

  • Approves the configuration baseline and changes to it
  • Approves or rejects MFA and policy exceptions
  • Decides on escalated security events, such as suspending an account
  • Sets the schedule and scope of access reviews
  • Attends the service review and accepts or challenges the open risks
  • Requests evidence packs for audits and examinations

Cannot

  • Approve a change they requested themselves, where a second approver is named
  • Edit or delete the change history or the Okta System Log
Approvals
Approves baseline changes, policy changes and exceptions; changes they request themselves are approved by a second named approver.
Notified about
Changes waiting for approval, escalated security events, exceptions reaching their review date and access reviews overdue.

IT administrator

IT manager, systems administrator, help desk lead

The institution's day-to-day contact for the service, handling first-line user issues and requesting changes.

Sees

  • Users, groups and application assignments in Okta, within the delegated admin scope agreed
  • Open change requests and their status
  • Service tickets and their history

Does

  • Raises change requests and application onboarding requests
  • Resets authenticators and unlocks accounts after verifying the user, following the agreed procedure
  • Answers first-line user questions about sign-in and enrollment
  • Provides application details and test accounts for onboarding
  • Confirms changes work after Moraph applies them

Cannot

  • Change authentication policies, the baseline or administrator roles
  • Approve their own change requests or exceptions
  • Grant themselves additional Okta administrator rights
Approvals
Change requests they raise are approved by the information security officer or another named approver before Moraph applies them.
Notified about
Updates on their requests and tickets, planned changes and Okta maintenance notices that affect users.

Application owner

Business application owner, system owner, department head

Accountable for who has access to their application and at what level.

Sees

  • Users and groups assigned to their application
  • Access review tasks for their application
  • Requests for access to their application

Does

  • Approves or declines requests for access to their application
  • Completes access reviews, confirming or removing each user's access
  • States the risk level of their application for the baseline
  • Tests single sign-on and provisioning when their application is onboarded

Cannot

  • Change authentication policies or Okta configuration
  • Review access for applications they do not own
  • Approve exceptions to the baseline
Approvals
Their review decisions are carried out by Moraph or by provisioning in Okta; removals do not need further approval.
Notified about
Access requests for their application and access reviews assigned to them, with reminders when overdue.

Moraph identity engineer

Moraph identity engineer, Moraph platform engineer

Configures, changes and maintains the Okta tenant on the institution's behalf, under approved change requests.

Sees

  • Okta configuration, policies, applications and the System Log for the client tenant
  • Approved change requests and the baseline
  • Monitoring alerts raised for the tenant

Does

  • Applies approved configuration changes and records what was changed
  • Connects new applications for single sign-on and provisioning
  • Triages monitoring alerts and prepares escalations with a recommendation
  • Reviews Okta release notes and plans relevant changes with the client
  • Prepares configuration evidence for service reviews and audits

Cannot

  • Make a configuration change without an approved change request, except an emergency action the agreed procedure allows, which is reported straight away
  • Approve exceptions or changes to the baseline
  • Sign in to the institution's business applications as a user
Approvals
Every change they make needs the client's approval first; emergency actions under the agreed procedure are reviewed with the client afterwards.
Notified about
Approved changes ready to apply, monitoring alerts and Okta service notices.

Moraph service manager

Moraph service manager, client success manager

Accountable for the service as a whole: requests, escalations, reporting and the regular service review.

Sees

  • All tickets, change requests and escalations for the client
  • Service reports, MFA coverage and open exceptions
  • Open risks and actions from earlier service reviews

Does

  • Runs the service review and records the actions agreed
  • Tracks requests and escalations to closure
  • Coordinates with Okta support on platform issues
  • Prepares evidence packs requested by the client
  • Raises risks, such as exceptions past their review date, with the client

Cannot

  • Change the Okta configuration
  • Accept a risk on the client's behalf
Approvals
None of their own; decisions they raise go to the information security officer.
Notified about
Escalations, overdue requests and Okta incidents affecting the client.

Auditor or examiner (read-only)

Internal auditor, external auditor, regulatory examiner (under temporary access)

Reviews the identity controls and their evidence without being able to change anything.

Sees

  • The configuration baseline, policy settings and exception register
  • Access review results and change history
  • Evidence packs prepared for the period under review

Does

  • Reads the evidence provided within their scope
  • Requests additional evidence through the information security officer

Cannot

  • Change configuration, approve anything or see records outside their scope
  • Keep access after it expires
Approvals
Their access is approved by the information security officer, with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the person who approved it.

Permissions at a glance

ActionSecurity leadIT adminApp ownerMoraph eng.Moraph serviceAuditor
Approve the configuration baselineApprovesNo accessNo accessNo accessNo accessView only
Request a configuration changeFullFullOwn work onlyNo accessNo accessNo access
Apply a configuration changeApprovesNo accessNo accessFullNo accessNo access
Change authentication policiesApprovesNo accessNo accessFullNo accessNo access
Approve an MFA or policy exceptionApprovesNo accessNo accessNo accessView onlyView only
Reset a user's authenticatorsView onlyFullNo accessFullNo accessNo access
Assign users to an applicationView onlyFullApprovesFullNo accessNo access
Complete an access reviewView onlyNo accessOwn work onlyNo accessView onlyView only
Decide on an escalated security eventFullView onlyNo accessView onlyView onlyNo access
Grant Okta administrator rolesApprovesNo accessNo accessFullNo accessNo access
View change history and System LogView onlyView onlyNo accessView onlyView onlyView only
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Moraph engineers apply changes; your institution approves them. Nobody approves a change or exception they requested themselves when a second approver is named.
  • Moraph staff use named, individual administrator accounts in your Okta tenant with only the admin roles the service needs, protected by phishing-resistant MFA. There are no shared administrator accounts.
  • Roles and delegated administration are agreed during implementation. Your IT team can keep first-line tasks such as authenticator resets, or hand them to Moraph.
  • Every administrator action is recorded in Okta's System Log, and every change is linked to its request and approval in Moraph's change record. Auditors and examiners get read-only evidence with a defined scope and end date.

Features

What it does

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

How it connects to your systems

Connects toHowWhat flows
Active Directory and LDAPOkta's directory agents connect to your on-premises directory so existing accounts and groups are used for sign-in and assignment.In: users, groups and account status from your directory.
HR systemWhere supported, your HR system becomes the source of identity, so hires, role changes and leavers drive account changes in Okta.In: worker records, job and department changes and termination dates.
Cloud and SaaS applicationsApplications are connected by SAML or OpenID Connect for sign-in, and by SCIM or Okta's provisioning connectors where the application supports them.Out: sign-in assertions and account create, update and deactivate requests.
Core banking and on-premises applicationsApplications 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.Out: sign-in for supported applications; exceptions recorded in the register.
Security monitoring (SIEM)Okta's System Log can be streamed to your SIEM or managed detection provider, alongside Moraph's own monitoring.Out: sign-in, MFA and administrator events.
Endpoint and device managementDevice signals from your endpoint management tool, such as Microsoft Intune, can be used in Okta policies where the integration is licensed.In: device management and compliance status.
Moraph service portalChange requests, approvals, exceptions, tickets and service reports are kept in Moraph's service portal, which your staff sign in to through Okta.Out to you: change records, exception register and reports.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

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.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Service operations

Change log

For information security officer and IT administrator

Every configuration change in the period, with the request, approver, date applied, test result and who applied it.

Break down by
Change type, Application, Approver, Period
Delivered as
Moraph service portal; CSV and PDF export
Used for
Confirming that every change was approved and recorded.

Requests and tickets

For iT administrator and Moraph service manager

Open and closed requests and tickets, with their age, status and who is waiting on whom.

Break down by
Request type, Status, Age band, Requester
Delivered as
Moraph service portal; CSV export
Used for
Keeping requests moving and spotting where the institution's input is needed.

Escalated security events

For information security officer

Identity events Moraph escalated, what was found, the recommendation and the decision recorded.

Break down by
Event type, User group, Outcome, Period
Delivered as
Moraph service portal; PDF export
Used for
Reviewing how identity events were handled and feeding lessons into the baseline.

Control coverage

MFA coverage

For information security officer, risk and compliance

Users and applications covered by MFA, the authenticator types in use, and users not yet enrolled.

Break down by
User group, Application, Authenticator type, Enrollment status
Delivered as
Service report; on request
Used for
Showing MFA coverage against the baseline and following up gaps.

Single sign-on coverage

For information security officer and IT administrator

Applications in the inventory, which are behind single sign-on and provisioning, and which are not and why.

Break down by
Application, Risk level, Integration type, Status
Delivered as
Service report; CSV export
Used for
Planning which applications to onboard next.

Exception register

For information security officer, internal audit

Each open exception to the baseline with its owner, reason, compensating control and review date.

Break down by
Exception type, Owner, Review date, Status
Delivered as
Moraph service portal; PDF and CSV export
Used for
Making sure exceptions are reviewed and closed rather than becoming permanent.

Access governance

Access review results

For information security officer, application owners, internal audit

Each review campaign, the decisions made by each reviewer, removals requested and when they were carried out.

Break down by
Campaign, Application, Reviewer, Decision
Delivered as
On completion of each review; PDF and CSV export
Used for
Evidencing periodic access certification.

Leaver deactivations

For information security officer and IT administrator

Leavers in the period, when their Okta account was deactivated, and connected applications where deactivation was confirmed.

Break down by
Department, Application, Period
Delivered as
Service report; CSV export
Used for
Showing that leavers lost access in connected applications and finding those that need manual follow-up.

Privileged accounts

For information security officer

Accounts with Okta administrator roles or access to high-risk applications, with their authenticators and last sign-in.

Break down by
Role, Application, Authenticator type, Last sign-in
Delivered as
Service report; on request
Used for
Keeping privileged access small and strongly authenticated.

Regulatory and audit

Examiner evidence pack

For internal audit and examiners

Baseline, policy settings, MFA coverage, exceptions, access reviews and change history for a selected period.

Break down by
Period, Control area, Application
Delivered as
On request; PDF with CSV attachments
Used for
Answering audit and examination requests without assembling evidence by hand.

Service review summary

For information security officer and senior management

Changes, escalations, coverage, open exceptions and open risks for the period, with actions agreed at the service review.

Break down by
Period, Topic
Delivered as
PDF after each service review
Used for
Giving management a record of how the identity service was run.

Exports, access and evidence

  • Service reports are prepared by Moraph from Okta's System Log and reports and from Moraph's own change and ticket records.
  • Reports respect each viewer's role: application owners see their own applications, and auditors see only the evidence within their scope.
  • Okta's own reports and System Log remain available in the tenant to the administrators you authorize.
  • System Log data can be streamed to your SIEM or data platform for retention and analysis beyond what Okta keeps in the tenant.
  • Requesting and exporting an evidence pack is itself recorded, so you can show what was given to whom.

Deployment

Where and how 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.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

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.

Limitations

What it does not do

Worth knowing before you evaluate it.

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

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

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

Questions

Frequently asked questions

Do we buy Okta from Moraph or from Okta?

Either. Moraph can resell the subscription, or run a tenant you already license. In both cases Okta's terms apply to the licence.

Who can change our configuration?

Named Moraph engineers, under change requests your approver has approved, and your own administrators within the scope you keep. Emergency actions follow a procedure agreed with you and are reported straight away.

Does this make us compliant with the FFIEC guidance?

No product does that on its own. Moraph configures controls with reference to the guidance and your risk assessment and keeps the evidence; your institution decides whether the controls are adequate, and examiners reach their own view.

What happens if Okta has an outage?

Okta's own service commitments and incident process apply. Moraph tells you when an incident affects you, and the break-glass plan agreed during implementation covers access to critical systems.

How is it priced?

Okta licences are priced per user under Okta's terms, and the managed service and implementation are quoted separately. See Working with Moraph for what drives a quotation.

Can we take the service back in-house?

Yes. The tenant and its configuration are yours; at the end of the agreement Moraph hands over the baseline, documentation and change history and removes its administrator accounts.

Next steps

Evaluate Identity Access Management

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Identity Access Management guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Identity Access Management support guide.

Related products