The Access That Survives a Password Reset

Reset the password. Revoke the sessions. Collect the laptop. Close the offboarding ticket.

That sequence is correct, and for one entire category of access it is beside the point. Their credentials are gone. The permissions they granted to third-party software on the company's behalf are still sitting in the tenant, still valid, still reading mail or files on a schedule nobody remembers approving.

These are OAuth application grants. They are the connective tissue of a modern Microsoft 365 environment — the mechanism by which a scheduling tool reads calendars, a CRM syncs contacts, a backup product touches SharePoint, and an AI assistant learns enough about a business to be worth its subscription. They are also, in our assessment, the least governed form of standing access in the average mid-sized company.

What a password reset retires, and what it leaves on file

Access to a cloud tenant is not password-based at the moment of use. It is token-based. A user authenticates once, a token is issued, and software presents that token rather than re-authenticating a human every time it needs something. That is a property of the protocol, not a configuration choice.

Precision matters here, because the common assumption is wrong in an instructive way. Resetting a password can invalidate the refresh tokens an application currently holds for that user. What it invalidates is the key, not the agreement. The consent record stays exactly where it was, and the moment that account signs in again, the application is entitled to a fresh token. Permission was interrupted, never withdrawn.

Grants come in two shapes, and the difference governs how an executive should reason about the risk.

• Delegated permissions. The application acts on behalf of a specific user and can reach only what that user can reach. Tied to a person, and therefore at least theoretically constrained by that person's lifecycle.
• Application permissions. The application acts as itself, through its own identity in the directory, with its own credentials. No user sits behind it. No password. No MFA prompt. No human whose departure would ever trigger a review.

Revoking sessions is one administrative action. Removing an application's consent is a different one, in a different part of the admin center, and it is the only step that reliably ends the relationship. Most offboarding checklists perform the first, sometimes the second, almost never the third.

Application permissions are the sharper edge. Because such an app holds its own identity, the Conditional Access policies written for people generally do not apply to it — protecting non-human identities requires deliberate, separate policy. Offered as analysis rather than alarm: an attacker who obtains an application credential inherits access that never looks like a suspicious sign-in, because it is not a sign-in at all. It looks like the integration the finance team asked for in March.

The consent screen is a procurement decision nobody treats as procurement

A department head evaluates a promising tool. The trial opens with a dialog box requesting permission to read mail, read all files the user can access, maintain access to data it has been given access to, and sign in on the user's behalf. Accept. The pilot proceeds. The vendor is never selected, the project dies quietly, and the grant remains.

Weigh the asymmetry honestly. Most organizations have a purchasing process for a software contract of any meaningful size — quotes, security questionnaires, perhaps legal review. The same organization allows a manager to hand an unvetted vendor persistent programmatic read access to executive mailboxes, at no cost, in a single click, with no record generated that anyone outside IT would ever see. Nothing malicious is happening. The imbalance is architectural, which is why it is worth fixing at the policy layer rather than by asking people to be more careful.

App consent is best treated as a cybersecurity control and a third-party risk control at the same time. A grant is a contract. It simply is not filed anywhere a CFO would think to look.

AI assistants widened the permission request

The genuinely new pressure in 2026 — again, analysis rather than prophecy — is that an assistant's usefulness scales with the breadth of what it can read. A tool that sees one folder is a novelty. A tool that sees the mailbox, the drive, the meeting history and the chat archive becomes the thing people refuse to work without. Vendors understand this, so requested scopes have widened, and requests for offline access — the ability to keep working while nobody is signed in — read as standard rather than exceptional.

Agentic tools push further still. An agent that files expenses, drafts replies or updates records needs write permission and needs to act unattended. That profile deserves a named owner, a review date and a documented business justification. Typically it arrives through the same one-click dialog box as a calendar plug-in.

Shadow AI is usually framed as a data-leakage problem: staff pasting confidential material into consumer chatbots. That framing is incomplete. The more durable exposure is the grant left behind — an application nobody uses anymore that still holds standing permission to read everything, with a client secret sitting on a server operated by a company whose security posture was never assessed and whose acquisition you will not hear about.

What a defensible grant register looks like

None of this requires an expensive platform. It requires treating grants as inventory. For Los Angeles companies in the twenty-to-five-hundred-seat range, the work is narrow and finite:

• Turn off unrestricted user consent and route requests through an admin consent workflow. People can still ask. Someone accountable answers.
• Enumerate every enterprise application in the tenant and separate those holding application permissions from those acting for a user. The first list is short and deserves real scrutiny.
• Assign a human owner and a review date to each retained grant. An application with no owner is an application to remove.
• Track credential expiry for app secrets and certificates, so integrations fail during business hours rather than at two in the morning.
• Revoke deliberately, not in bulk. Some of these grants are load-bearing. Confirm the owner and the dependency before cutting, or a cleanup becomes an outage.
• Add grant revocation to two runbooks — employee offboarding and vendor offboarding. Ending a contract should end the access.
• Include app-only access in identity-compromise response. If an account is breached, revoking sessions is insufficient when the attacker registered a grant first.

The initial pass is a finite project. Maintained afterward, it is a quarterly conversation.

The question worth asking at your next IT review

Ask your IT leader or provider for a list of every third-party application holding standing permission in the tenant, sorted by the breadth of what it can read, with an owner named beside each entry. The list itself is the deliverable. If it cannot be produced quickly, that gap is the finding, and it is more useful than another debate about password policy.

The executive point is narrow and should outlive this article. Identity is the perimeter, and that perimeter now includes software that never sleeps, never leaves the company and never forgets what it was once allowed to do. Governing people is table stakes. Governing the grants those people issue is the part most organizations have not started.

Pro Link Systems has supported Los Angeles businesses from Woodland Hills since 1999, with a 24/7 in-house, US-based help desk behind the work. If you want that inventory produced for your own tenant, our managed IT services team can build it.