In view of its absence of native IAM integrations, this application will suffer from a low-grade security posture and high maintenance costs.

An alternative application should be considered and contact should be taken with the editor to gain visibility on its development roadmap.

Natively, the application only supports password-based authentication.

To implement more robust authentication mechanisms and/or implement SSO, application virtualization may be an option.

The application supports the configuration of a password policy.

Align it to your organization’s password policy.

The application supports the direct granting of fine-grained entitlements to identities and/or their grouping into roles.

A typical best practice is to avoid direct fine-grained access permissions and systematically grant access permissions via roles. Application roles may then be mapped to IAG entitlements or roles.

The absence of native IAM integrations gives no choice but to provision and administer the application manually.

A typical SoD requirement is to enforce segregation between application provisioners, administrators, and functional users.

The absence of an API makes it impossible to automatically reconcile this application with IAG authorizations.

Include this application in your manual application reconciliation control plan with frequency proportionate to its sensitivity.

No native support for PAM solutions.

Applicative administration may be forced via a bastion. Password automatic rotation will require client-side scripting which comes with additional development and maintenance costs. The possibility of bypassing the bastion must be analyzed, especially if the administration and functional clients share the same protocols. If bastion bypass cannot be technically avoided.

The absence of logging features makes this application isolated from your SIEM.

This may be partially compensated with logging and event correlation at the client, application virtualization, and/or server level.