“Function not authorized” in a key programmer: activation or incompatibility?

“Function not authorized” means the tool has refused the selected operation; it does not by itself prove that a subscription is missing or that the vehicle is incompatible. Separate account activation, online entitlement, software coverage, selected vehicle variant, and local module communication before changing vehicle data or purchasing anything.

Authorization refusal defined: an authorization refusal is a tool or service response that blocks an operation before or during its workflow. The exact words, timing, vehicle selection, tool version, and account state determine which boundary is being reported.

What does “function not authorized” mean on a key programmer?

Capture the entire screen, not only the headline. Does the message appear before connecting to the car, after account sign-in, after vehicle identification, or when a security operation starts? A pre-vehicle refusal points toward tool account or entitlement. A refusal after the tool identifies a different module can point toward database coverage or platform selection. A no-communication error is different again: it is evidence about the vehicle-side path, not an activation decision.

Autel’s official support page documents account login, activation-code redemption, and subscription handling. Autel’s update and activation instructions provide a primary source for vendor account actions. They cannot tell whether another vendor’s refusal is an entitlement issue.

Activation problem or vehicle incompatibility?

In a worked case, the tool is signed in, its update page opens, and the selected 2021 vehicle menu reaches a BCM identification screen. The refusal appears only when an online function is selected. Record the 2021 market, BCM number, database release, account status, and error code. That five-fact record can distinguish a missing entitlement from an unlisted variant. Repeating the command five times adds no useful fact and can create risk if the operation later reaches a write phase.

Why updating is not the automatic answer

An update may add coverage, correct a database error, or restore a service component. It may also leave the same refusal because the account lacks the required privilege or because the chosen vehicle is not covered. Firmware, database, and subscription checks should be performed separately. Confirm current versions before a vehicle is put into a security session, not while the session is active.

Do not select a similar year or market to bypass a missing menu. A similar body style can contain a different immobilizer architecture. Identifying the module that owns the function comes before the selection of any programming route.

What an authorization message does not mean

It does not prove that the key is wrong, that the BCM is defective, or that bench work is required. It does not prove a subscription has expired unless the official account record says so. It does not justify sharing account credentials, searching for an undocumented bypass, or launching an erase function in a different menu. A refusal can be the safest outcome because it prevents an unsupported action.

Ford’s PATS documentation treats security access as a named condition within specific procedures. The Ford PATS/RKE Dealer Aid shows why security access, key code erase, and key programming must be read as distinct steps. Do not transfer its procedures to another platform.

Common mistakes after a refusal

• Assuming “not authorized” means “buy an update”: verify the exact category first.
• Changing vehicle selection until a menu opens: a menu is not proof of compatibility.
• Retrying an online command during unstable power: stabilize vehicle state first.
• Sharing screenshots with secrets visible: redact tokens and security values.
• Removing a module after an account error: solve the tool-side boundary first.
• Erasing keys to test support: retain working credentials and preserve evidence.

Boundary and final check

This diagnostic method does not bypass licensing, account control, or vehicle security. If entitlement or coverage cannot be demonstrated, stop and seek the authorized route. Internet access is only one possible requirement and cannot repair a wrong platform selection.

When an authorized procedure is completed, verify one lock, one unlock, one engine authorization, and passive entry or emergency-reader operation if fitted. Record the four outcomes and the exact refusal that was resolved; that is evidence of a repair rather than a claim that a menu finally opened.

A short refusal record

Record six facts: full wording, time, tool serial or model, database release, account state, and selected vehicle/module. Add whether the tool could communicate with the vehicle before the message. That record gives support or an authorized administrator something testable and prevents an operator from changing modules, keys, and subscriptions all at once.

When the message is resolved, do not assume the vehicle work is done. Re-identify the module, review the operation warning, stabilize voltage, and confirm the protected key inventory before starting the actual documented procedure.

Do not erase the refusal evidence after signing in or updating. The original wording, before-and-after version numbers, and time of the event allow a later comparison if the same operation fails on the same vehicle again.

Where the official account page confirms an entitlement but the operation still refuses, preserve that contradiction and check exact coverage, vehicle market, and module identity. It is useful evidence for authorized tool support; it is not evidence that a similar vehicle menu is safe to use.

A disciplined refusal record also protects a working vehicle: it establishes that no destructive operation was performed while the tool could not establish support. Preserve that fact together with the physical key inventory.