The most important legacy application in an organisation may not look like a legacy application. It may look like an Excel workbook: familiar, useful, business-critical and quietly outside the identity model the rest of the enterprise now expects.
When a workbook becomes an automation client, authentication becomes part of the transaction itself.
Why usernames are not enough
A username is a label. It is not proof. It does not say whether MFA was enforced, which identity provider issued the sign-in, what claims were present, whether the session is still valid or whether another system should trust the context.
For simple reporting, a username may feel sufficient. For Orchestration calls, API calls and cross-system workflows, it is not. The receiving system needs trust, not just text.
What modern identity adds
Modern identity gives the workbook a real authentication event. The user signs in through the browser. The identity provider enforces policy. MFA happens centrally. The result is a verified identity and, where scopes and audiences are configured appropriately, token material that other approved systems may accept.
- SSO reduces local password prompts and password reuse.
- MFA keeps Excel automation aligned with enterprise policy.
- Claims provide context: user, domain, groups, roles or other attributes.
- Tokens can carry identity forward to systems that trust the issuer and audience.
How Beanstalk fits
Beanstalk Excel MFA and SSO is designed for this exact gap, with the broader Beanstalk Authentication Broker product behind it. Excel, VBA, Access and other COM-capable Windows applications call Beanstalk. Beanstalk opens the browser and completes the OIDC/PKCE flow with the identity provider. The application receives a verified identity result rather than handling credentials itself.
That is the difference between a macro that merely knows a name and an automation client that participates in the enterprise identity model.
A necessary token caution
Tokens are not magic passports. They have audiences, scopes, expiry and validation rules. A token issued for one system should not be assumed valid for another. But when the architecture is designed correctly, token material can let approved systems recognise the authenticated context without asking the user to sign in again or smuggling passwords through a workbook.
The trust chain
The chain should be clear: the user authenticates to the identity provider; the workbook receives a verified result through Beanstalk; JDE Orchestrations or other services receive calls with a trustworthy context; audit can show who requested the action. No shared secret. No hidden password. No convenient fiction.
That is exactly the kind of exception Beanstalk is meant to close: familiar front end, modern identity, verified context and no passwords buried in VBA.