Why the default Fineract login must be replaced before go-live
If your team has a Fineract build running in infrastructure you control and real customer data is about to arrive, the first credential change is non-negotiable. The Fineract README documents a default development login of mifos with the password password and states that it must be changed for any real deployment. Treat that login as a known public credential until it is removed, and confirm before go-live that no environment, seed script or test fixture still accepts it.
This page covers four areas that sit between a working build and a safe production instance: replacing the default credentials, confirming that no test or development Spring profile is active in the production runtime, choosing between HTTP basic and OAuth2 authentication for API callers, and watching logs for the warnings that Fineract's development configuration emits. Each area has its own check, and each should be signed off by the team that will operate the system, not only by the team that built it. The sections that follow give the steps in that order.
The README does not provide a comprehensive production deployment guide and warns that production deployments can be complex and time-consuming, so the default-login item should not be read as the full hardening list. Ask your implementation team to show you, in writing, every credential source in the build, including image environment variables, tenant configuration and CI pipelines, and to name the owner of each. Where a configuration item is not covered by the supplied project documentation, confirm its behavior against the release you deploy rather than assuming a default.
Which authentication option fits which deployment
This table compares HTTP basic authentication and OAuth2 for a Fineract deployment across the decision factors that matter before go-live. Read each row as a question to answer for your environment, then confirm the vendor-level details with the project documentation before you commit.
| Decision factor | HTTP basic authentication | OAuth2 |
|---|---|---|
| Best fit | Small internal deployments with few API consumers and no central identity provider | Deployments that must sign users in through an existing identity provider or serve several client applications |
| Integration with an existing identity provider | Usually limited to Fineract's own user store, so central joiner and leaver processes must be applied by hand | Can federate with your identity provider, so access follows your central directory, subject to configuration you verify |
| What the operator manages | Strong password rules, rotation of the stored login, and TLS on every request, since credentials travel with each call | Authorization server settings, client registrations, redirect and scope configuration, and signing key handling |
| Service-to-service use | Simple for batch jobs and scripts, but a shared login spreads across systems and is hard to attribute | Service identities can hold separate client credentials, which supports per-system attribution |
| How credentials reach clients | The client sends the username and password, encoded, on every request | The client obtains a token from the authorization server and presents it to the API |
| Token lifetime handling | Not applicable, since there are no tokens to expire | Lifetimes and refresh behavior depend on the authorization server, so confirm the settings you will run |
| Monitoring and audit | Failed logins and API activity must be traced through Fineract logs and your gateway, with the account name as the only identity | Token issuance and validation events can be logged by the authorization server and correlated with Fineract activity |
| Confirm before go-live | Which password policy applies to the API user, and whether the default login is removed in your build | The exact OAuth2 configuration, supported grant types and token settings for your Fineract version in the project documentation |
Pre-go-live steps to remove defaults and insecure profiles
This sequence takes a Fineract deployment from inherited development settings to a production configuration in which the default login is gone, every instance runs only the profiles it should, the authentication mode is chosen deliberately, and HTTPS is enforced. Each step closes with a check that proves it is done.
Inventory every environment, image and tenant
The platform team lists each environment (development, test, staging, production), each container image or build artifact, each write, read and batch instance, and each tenant registered in the tenants database. Include any copies made for testing or support. The output is a written register that names the owner of every item. You know this step is done when the register accounts for every running instance and every tenant, and someone other than the author has reviewed it against the live cluster or host list. Confirm with your own infrastructure records which images are in use, since the project does not dictate your release pipeline.
Replace or disable the default mifos account
The Fineract README documents a development login of mifos with the password password and states that it must be changed for any real deployment. In each tenant, the security team or the Fineract administrator creates named administrative users with strong credentials, assigns roles through the platform's existing user management, and then disables or removes the mifos account. Do this in every tenant, not only the default one. Done means the sign-in test in a later step fails for mifos in every tenant, and no admin account in the register uses a shared or default password.
Confirm active Spring profiles on each instance
Check the Spring profiles set on every write, read and batch instance, using the environment variables or deployment manifests that configure each instance. Look for development or test profiles that enable sample data or relaxed settings, and for the liquibase-only profile, which should run only in the migration job it is meant for. Record the effective profile list from the running process, not only from the manifest, because overrides can exist in more than one place. Done means every instance reports the profile set you approved, and the log check in a later step finds no unexpected profile warnings.
Choose the authentication mode for production
Decide whether production uses HTTP basic authentication, OAuth2 through your identity provider, or a documented combination, and record the reason. Basic authentication relies on each client holding a credential that must be protected and rotated. OAuth2 moves sign-in to an identity service you operate, which changes how accounts are provisioned, disabled and audited. Confirm with your identity team how token issuance, session lifetime and offboarding will work, and confirm the exact configuration keys for your Fineract version in the project documentation. Done means a signed decision record exists and the chosen mode is the only one enabled in the production configuration.
Enable HTTPS through the documented SSL settings
Enable TLS on the Fineract server using the SSL environment variables described in the project documentation, such as FINERACT_SERVER_SSL_ENABLED, and provide certificate material from your certificate management process. Plain HTTP should not be reachable from clients or from the gateway to the application. Verify the certificate chain and protocol settings with your standard scanning tools. Done means a request over plain HTTP is refused or not answered, a request over HTTPS completes, and the certificate chain validates from a client host that does not trust any extra roots.
Verify with a failed login test
Run a scripted sign-in attempt with the former default credentials against every tenant and every externally reachable endpoint, and record the HTTP status for each. Then run a sign-in with a valid named account to confirm the control does not block legitimate use. Include the tenant identifier header in each request, since tenant scope affects which accounts are checked. Keep the test results, timestamps and tester name as evidence. Done means every default login attempt is rejected, every valid account succeeds, and the results are filed with the change record.
Verify profiles and scan logs for test warnings
Restart or redeploy the instances in a controlled window, then repeat the profile check against the running processes and search the startup logs for the warning text that marks non-production builds, including DO NOT USE THIS IN PRODUCTION. Add a standing alert on that text in your log platform so a later misconfiguration is noticed. Done means no instance reports a test profile, no startup log contains the warning, and the alert fires correctly when a test message is injected into a non-production stream. Keep the log search query and alert definition in version control with the runbook.
Confirming no test profile is active in production
Check the running configuration, not the intended one, to confirm that no development or test profile is active in production. Fineract uses Spring profiles together with environment variables to set how an instance behaves, including whether it acts as a write, batch or read instance. The same mechanism selects the liquibase-only profile, which exists so that database migrations can run as a separate job on Kubernetes rather than at application startup. Your deployment should use that profile deliberately and for that purpose only. Ask your platform team to list the active profiles and the environment variables that feed them for each running pod or process, and compare that list against the deployment manifest in source control. Any difference is a finding.
Look also for leftover sample configuration. Development builds and example files often carry settings meant for a local laptop, such as the default login, permissive hosts, or sample database connections. Confirm that none of these files are packaged into the image you deploy, and that the image tag, configuration source and secret references match the release you have tested. Exact profile names, and the behavior of any profile that writes warnings to the log, must be verified against the Fineract version you run, using the Apache Fineract platform documentation and the project source. Do not rely on names remembered from an earlier release or from a community tutorial.
Record the result as evidence before go-live. A short written check should name the release, the profiles and variables observed, who reviewed them, and the date. Repeat the check after every upgrade, configuration change or image rebuild, because a profile that was harmless in a test environment is easy to carry forward by copying a configuration file. Ask your implementation partner, or confirm internally, how the check is automated in your pipeline and how a deviation blocks a release.
Reading logs for DO NOT USE THIS IN PRODUCTION warnings
Test profiles and default logins often leave a trace in startup output before anyone notices them in the API. The cards below set up parallel checks that catch those traces, route them to an owner, and stop a build from moving forward while they remain.
Collect startup logs from every instance
Capture startup output from every Fineract instance, including write, batch and read instances, in a central store that keeps logs for the length of your change and audit window. A warning on one container is easy to miss if only one pod is shipped to the log platform. Confirm with your platform team which log driver or agent forwards container stdout, and check that the forwarder runs in every environment, not only production.
Alert on the exact warning text
Create alert rules that match the DO NOT USE THIS IN PRODUCTION phrase and any profile-activation lines your build prints at startup. Copy the wording from a real startup log of the exact build you run, because the text can change between releases. Match on the phrase in a case-sensitive way and alert on any occurrence, not only on error level, since these warnings are often logged at a lower severity.
Test that alerts actually fire
Start a disposable instance from the production image with a test profile enabled, confirm the warning appears in the store, and confirm the alert reaches the on-call channel. Repeat this after each change to the logging pipeline, since a parser update can silently break matching. Record the test result as evidence for your change record, along with the image digest used.
Review logs after each deployment
After every deployment, search startup logs for the warning phrase and for the active Spring profile list, then compare them with the approved baseline for that environment. Treat any unexpected match as a failed release. Keep the review in the deployment runbook so the person promoting the build signs off on it, and run the same review after rollbacks.
Block promotion and assign an owner
Make the warning a gate in the pipeline so that a build producing it cannot move to staging or production without a documented exception. Name one owner for the platform team who triages alerts within an agreed window, and a second owner in security who approves any exception. Confirm with your change board who can grant an exception and how long it can last.
Questions teams ask before removing Fineract defaults
How much effort does removing Fineract defaults take?
The effort depends on how many environments, tenants and integrations touch the default login and profiles, and on how much of the check is automated. The core work is small in concept: replace the development login, confirm that no test profile is active in any running instance, choose the authentication mode, and review logs during startup and early traffic. Effort rises when there are several tenants, separate write, batch and read instances, custom container images, or downstream systems that still use the old credentials. Ask any partner for a written scope that lists each environment and instance type it will check, and for the evidence it will deliver.
Can our internal team remove the defaults alone?
Often yes, if the team has Fineract deployment experience, access to the container images and configuration, and an identity provider or basic authentication plan they can operate. The gaps usually appear in verification: confirming that every instance, including batch and read instances, runs without the test profile, that no image or environment file carries the development login, and that logs show no DO NOT USE THIS IN PRODUCTION warnings after startup. An internal team can also ask an independent reviewer to check the result before go-live. The decision depends on your in-house skills and how many environments you run.
What do we need to provide for this work?
Plan to provide the following before work starts:
- Read access to deployment manifests, container images, environment files and the tenants configuration
- Named owners for the identity provider, if OAuth2 is chosen, including client registration and token settings
- Change windows for each environment, with a rollback plan for authentication changes
- A list of client systems, scripts and batch jobs that currently call the API with the default login
Agree on who approves the final authentication mode and who signs off the go-live check.
How much does this check add to go-live planning?
No fixed duration applies, because it depends on the number of environments, the authentication mode chosen and how quickly client systems can switch credentials. Treat the check as a gate in the go-live plan rather than a separate project. Build time for the identity provider integration, if you choose one, usually takes longer than the profile and credential review itself. Ask any partner to state the duration against your written scope, and confirm with your change board how authentication changes are scheduled.
Can a vendor attest that Fineract is secure after this work?
No. DeployOpen plans, implements, hardens and documents Fineract deployments, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. For this topic, the evidence may include configuration records, startup log captures, and a checklist showing that default credentials and test profiles were removed. Independent auditors or certification bodies decide whether that evidence meets the framework you are assessed against.
Should we choose basic authentication or OAuth2?
Choose based on your identity architecture and operating model. Basic authentication is simpler to configure but puts credential management inside Fineract's user base and requires strict password handling. OAuth2 connects Fineract to an identity provider, which centralizes sign-in, MFA and account lifecycle, but adds integration work and token configuration. Confirm the supported options for your Fineract version in the platform documentation before deciding, and document the choice with its owner and review date.
How do we know the default login is gone?
Test it directly. Attempt to authenticate with the development login against every tenant and instance type, and confirm the request is refused. Search container images, Helm values, environment files and source control for the default values. Then review startup logs for warnings about test profiles or DO NOT USE THIS IN PRODUCTION messages, and set an alert so any reappearance after a deployment is reported. Keep the results with the change record so auditors can trace them.
How DeployOpen scopes and verifies Fineract hardening
DeployOpen scopes this check in writing before any work starts. The written scope lists each default credential, Spring profile and authentication setting to be reviewed, the environments covered (development, test, staging and production), the instance types in scope (write, batch and read instances, as described in the Fineract documentation), and the evidence the client will receive. Most engagements of this kind are fixed-scope, so deliverables and timelines are agreed in advance and a quote follows from that document. The client's team confirms which authentication model it intends to use, basic authentication or OAuth2, because that choice changes which checks apply.
The work runs inside the client's own infrastructure, using the client's container images, Kubernetes manifests or deployment pipeline and their secrets store. For each item, DeployOpen records the starting state and the change made, then verifies the result: the mifos login is rejected, the password secret no longer works, no test or development profile appears in the active profile list of any running instance, and the DO NOT USE THIS IN PRODUCTION warning is absent from startup logs. Each check is repeated on the production-like environment that matches the release being deployed, not only on the environment where it was first fixed. Verification output, configuration diffs and log excerpts go into the handover pack, so the client's auditors and internal reviewers can trace each control to a result.
The handover includes a written runbook and a recurring check that the team can run after every upgrade or configuration change. Because new Fineract releases ship quarterly and can change default settings, the recurring check is the part that keeps the result valid over time. Clients who prefer that DeployOpen keep running it can take a retainer for ongoing support, upgrades and periodic testing. Clients who prefer to run it themselves receive the scripts and the instructions to do so. Confirm with DeployOpen during scoping which of these two models fits your team, and ask for the handover contents and the retest approach to be named in the quote.
