Copilot Studio Connector Authentication Keeps Expiring: Fix

Official documentation checked October 14, 2026.

Repeated sign-in requests from a Copilot Studio connector do not automatically mean its access token needs a longer lifetime. The agent’s user sign-in, the connector connection, the API’s authorization, and your organization’s session policies are separate layers. Repair the layer that failed without changing whose permissions the tool uses.

Do not remove Conditional Access requirements, create never-expiring API keys, or switch to a shared privileged account simply to stop prompts. Those changes can hide the symptom while exposing data or actions to the wrong users.

1. Identify which connection is actually expiring

Record the agent and environment, affected connector and operation, published channel, account used, timestamp, and complete error code. Distinguish these patterns before changing anything:

• Sign-in once for a new connector: a separate connection can legitimately require its own sign-in or consent.
• The same connection immediately asks again: investigate whether sign-in completed and whether the tool is bound to the expected connection.
• Failure begins after a password, credential, or policy change: check revocation, credential validity, and sign-in-policy results.
• Only other users fail: compare their service permissions and runtime identity with the maker’s successful test.

In the agent, open Settings > Connection Settings. Find the connection and inspect its associated tools and status. An Expired status calls for reauthentication; Stale calls for reviewing and updating or replacing the connection. Use the status link to open the connection dialog and select the intended existing connection or create the required one. Microsoft’s connection-management guide describes these states and controls.

2. Reconnect with the intended identity

1. Confirm whether the tool is intended to run with the end user’s credentials or an explicitly approved maker-provided connection.
2. Reauthenticate the affected connection with the intended account and tenant. Complete any legitimate consent or multifactor-authentication step.
3. Check that the tool references that connection, then test a harmless operation such as reading one approved test record.
4. Repeat in the published channel with a normal test user. A maker’s successful test does not prove other users have a working connection or appropriate access.

Connector tools use end-user credentials by default; maker-provided credentials are a different execution model. Microsoft explains the tool configuration in adding connector tools. Do not change that model merely because the maker’s account can sign in successfully.

If the failure involves a custom connector’s client secret or an API key, have its owner check the credential in the provider’s administration interface and update the connection through the supported secret-management process. Do not paste secrets into agent instructions, conversations, screenshots, or support tickets. Reauthentication will not repair a disabled API account or restore permission to a removed resource.

3. Investigate why the failure returns

For Microsoft Entra authentication, ask the identity administrator to correlate the failure time with sign-in logs and the applicable Conditional Access result. A sign-in-frequency requirement can deliberately request a new login. Setting it to Every time does not reduce prompts, and an organization-wide exclusion is not a connector repair. See Microsoft’s session-control explanation.

Do not try to set a universal 90-day refresh-token lifetime in an Entra portal blade. Microsoft no longer supports configuring refresh-token or session-token lifetimes through token-lifetime policies. Access-token behavior also varies; changing an access-token lifetime is not a general fix for broken refresh or consent. The current limits are documented in configurable token lifetimes.

For custom connectors, verify the API provider’s supported authorization flow, redirect URI, token endpoint, scopes, and credential validity against the connector definition. Power Platform custom connectors do not support the OAuth client-credentials grant as a selectable workaround. Use the custom-connector authentication reference, not an assumed generic OAuth dropdown.

There is no universal hourly topic that keeps every connection authenticated forever. Consent approval, session renewal, and credential rotation solve different problems. A legitimate account revocation must continue to stop access.

4. Verify recovery without weakening authentication

Use a small test record that the affected user may read. After reconnecting, test the same operation immediately, later in a new conversation, and after the interval at which the failure previously appeared. Preserve timestamps and outcomes so support can distinguish a repeatable loop from expected periodic sign-in.

Also test a user who is not allowed to read the record. Under an end-user connection, that user must not gain access through the agent. If the tool instead uses a maker-provided connection, reassess whether every intended agent user may receive the data and perform its actions. Microsoft warns that maker credentials can overshare permissions.

Escalate a continuing loop with the connection status, operation name, account type, channel, correlation ID if shown, and redacted error details. Do not share access tokens or reset unrelated connections. Call the incident resolved only when the affected path works with the intended identity and the required security controls remain in place; one successful request is not a promise that sign-in will never be needed again.