Freed capacity, realized savings and AI consumption are different measures. A useful pilot agrees how to measure outcomes before discussing value-based pricing.
Using OAuth does not settle credential custody. Environment copies, permissions and revocation deserve a review before connecting services or agents to an ERP.
Checked against the public session listing, dated October 29, 2026, and Microsoft documentation consulted on November 7, 2026. This article describes existing mechanisms whose compatibility depends on hosting, APIs and configuration. The registered PDF was inaccessible: its pages have not been verified or used as evidence.
Arend-Jan Kauffmann’s session listed by Directions for October 29, 2026, proposes examining the credential lifecycle in Business Central: creation, storage, retrieval and transmission. Its description includes database copies and authentication for external services among the areas to review. Public session listing.
Nexo’s editorial interpretation is practical: confirming that a connection obtains a token is insufficient to assess its operational security. Teams also need to identify who can use its credential, which operations it permits and how to stop access when it is no longer needed.
Identity, custody and permissions
In the OAuth client credentials flow, a service acts under its own identity without representing a user. Microsoft supports shared secrets, certificates and federated credentials for obtaining tokens in the relevant scenarios. The destination API must check the application’s authorization. Client credentials flow.
Business Central documents S2S for online APIs and web services from version 18.3, and automation APIs from version 17.0. For on-premises installations, support starts with versions 18.11 and 19.5 and requires Microsoft Entra authentication through OpenID Connect. The application must also be enabled in Business Central and assigned the necessary permissions; it cannot receive the SUPER permission set. S2S availability and configuration.
When reviewing an integration, Nexo suggests addressing these questions separately:
Identity: which application requests access?
Custody: where does the credential reside, and who can retrieve or use it?
Permissions: which data and operations does the integration actually need?
Removal: which procedure verifies that access has stopped?
An environment copy requires a connection review
Business Central takes precautions when copying environments: it stops job queue tasks, clears base application integration settings and blocks outbound HTTP calls from extensions by default. Those calls require approval for each extension. Documented copy behavior.
Our recommendation is to review each integration before reactivating it. These protections do not constitute an individual check of a custom extension’s credentials. The team must verify which configuration remains, which destination it will use and whether its access is appropriate for the test environment.
Choose the mechanism for the context
Microsoft recommends avoiding manually managed secrets when a compatible alternative exists, and prioritizes certificates when a managed identity or suitable external identity provider cannot be used. The choice requires checking both ends of the integration. App registration recommendations.
Mechanism
Where it fits
Limit to check
Managed identity
Supported Azure resources; the platform manages credentials.
The destination resource must support Entra authentication and grant access to that identity. Documentation.
Workload identity federation
Supported scenarios, such as GitHub Actions or Kubernetes, through trust in an identity provider.
That trust must be configured and restricted; it does not replace resource authorization. Documentation.
Certificate
Application authentication where the integration supports it.
The private key still requires custody and renewal. Microsoft recommends a secure vault.
Client secret
Integrations that use a shared credential.
Requires protected storage, rotation and expiry management; it must not be shared across applications.
Removing a credential and stopping access require separate checks
Microsoft’s documentation warns that deactivating an application prevents new tokens from being issued, while existing tokens remain valid until they expire. An administrative action should therefore not be assumed to terminate all existing access immediately. Application deactivation.
Nexo suggests rehearsing access removal in a controlled environment: test both a new token request and the use of a previously issued token, and record the destination service’s observed behavior. The procedure needs an owner and a verifiable completion criterion.
A useful inventory without copying secrets
This template is an editorial proposal for documenting integrations. Record references and responsibilities, never secret values, tokens or private keys.
Field
What to record
Integration and owner
Business purpose, owning team and operational contact.
Identity and environment
Application identifier, customer, environment and authorized destination.
Mechanism and custody
Credential type and reference to the vault or trust relationship.
Permissions
Required operations and the assignments that allow them.
Copying and renewal
Expected behavior when copying the environment and the credential renewal owner.
Access removal
Procedure, most recent test and observed result.
An example in practice
Hypothetical example: a team copies production to test an order connector. Before authorizing outbound calls, it checks the connector’s identity, the vault it references and the destination of its requests. It then tests access removal using test data. This is a proposed working scenario, not an incident or an observed outcome.
The editorial recommendation is to make credential review part of every integration handover: alongside the working connection, document who can use it, the scope of its access and how to withdraw it.
Created with AI assistance and reviewed by Nexo Community. Practical proposals and editorial interpretation are distinguished from documented facts.
GitHub announces a gradual rollout of the model. Teams considering adoption should compare correctness, review effort and cost per task, alongside checking effective access.