August 2025

Last update:
Aug 21, 2026
Welcome to the August release notes for the Aikyam Identity Platform. Here, you'll find detailed information about the latest updates, new features, improvements, and bug fixes.
Release date: August 21, 2025

Password policy update

Who?
Impacted OHID portals
  • USP Broker and Employer Portal (App ID: bep27643)
  • Employer eServices (App ID: EES80248
What?
The password policy will change to require 14 characters. This update will apply to users at the time of their next scheduled password expiration, rather than forcing everyone to change their password immediately when the policy is enabled in OHID.
Why?
This approach is required by the portal to prevent mass disruption and avoid negative NPS ratings.

Portal access controls

Who?
OHID tenant/portals
What?
  • End user portal login will require a client ID for tracking and controlling user access.
  • Standalone portals will be made private and inaccessible to unauthorized users.
Why?
Improved security posture: Enforcing OHID login ensures that only authenticated, legitimate users can access the portal, reducing the risk of unauthorized access and potential data breaches.

Aikyam Platform updates

  • Phase 1: Unauthenticated chat
  • Move Foundation (MVP)
  • Milestone 1 continues (dark deployment until all components are available)
Who?
Tenant
Impact (Yes/No)
OHID
Yes (with outage)
MAHIX
Yes (with outage)
BEWELLNM
Yes (with outage)
GOVID
Yes (with outage)
HSID
No impact
Release date: August 9, 2025

Tenant isolation

Who is impacted?
Tenant
Impact (Yes/No)
OHID
Yes (with outage)
MAHIX
Yes (with outage)
BEWELLNM
Yes (with outage)
GOVID
Yes (with outage)
HSID
No impact
What changed?
We introduced Multi-region Tenant Isolation on the Aikyam platform. In general , multi-region tenant isolation in a multi-tenant architecture ensures that each tenant (customer) within a shared application environment has their data and resources both physically and logically segregated across various geographic regions. The approach improved data residency, strengthened disaster recovery, and supported compliance, while still allowing tenants to benefit from shared infrastructure efficiencies.
Why?
Limit blast radius
Limiting the blast radius referred to designing systems or processes in a way that contained failures or issues within a small, well-defined area, minimizing their effect on the overall system. By doing so, organizations ensured that if something went wrong during a deployment or rollout, only a small segment of users or services was affected rather than the entire platform.
Strategies to limit the blast radius included deploying changes to a subset of servers or regions first, using feature flags to turn features on or off for select user groups, and monitoring early signals before a wider release. This not only helped catch issues quickly but also facilitated safer, more gradual rollouts, fostering resilience and reliability within the platform.
Addressing the noisy neighbor
The “noisy neighbor” problem referred to a scenario where one tenant’s high resource usage negatively impacted other tenants sharing the same infrastructure. This often manifested as performance degradation, increased latency, or even service disruptions for affected tenants. Effective management of this issue was crucial in multi-tenant environments.
Previous: September 2025
Next: July 2025

On this page

Powered by Aikyam @2025 All rights reserved