When did your PowerBuilder application last go through a security architecture review?

Your PowerBuilder application probably runs on implicit trust.

It was designed for a corporate network where users on the inside are trusted, database connections are direct, and there is no authentication boundary at the API layer — because there is no API layer.

That architecture made sense in 1998. In 2025 it is an attack surface, not a design choice.

Modern enterprise security requirements cannot be retrofitted onto a client/server PowerBuilder architecture without fundamental change:

Multi-factor authentication requires an identity layer the architecture doesn’t have. Token-based API authorization requires an API boundary that doesn’t exist. SIEM integration requires structured audit events at the transaction level — not available from a desktop client that talks directly to the database. Zero-trust network access requires every request to be authenticated at the service layer.

A properly executed modernization resolves all of this by design:

OAuth 2.0 with Azure AD or Okta issues JWT tokens. Every API call is authenticated and authorized by ASP.NET Core middleware. Fine-grained authorization — field-level visibility, transaction approval thresholds — is encoded in policy-based authorization. A full audit trail exists at the service layer, independent of the database.

The presentation layer replacement is what users notice. The security architecture improvement is what your CISO notices. The compliance exposure reduction is what your legal team notices.

When did your PowerBuilder application last go through a security architecture review?