A support group may issue new credentials for existing identities but may not edit any permission — what does that grant actually reach?
answer
- two halves: who you are, what you may do
- no permission document changes
- a new way to prove an identity
- reach equals the union of target principals
- constrain by which principals may be named
basics
~20 sIt reaches everything every identity it may issue for can do. Issuing credentials is authentication material, not authorization, so no permission changes anywhere — the holder simply authenticates as a stronger principal and acts as it.
solid answer
~40 sAuthorization decides what a principal may do; a credential only decides who gets to be that principal. A group allowed to issue a long-lived static credential for another identity, reset a human principal's login secret, register an additional second factor, or add its own public key to an identity is allowed to *become* that identity, so its reach is the union of the principals it may issue for. Nothing in the grant graph changes, which is why a review that reads permission documents alone finds nothing: the documents are all still correct. The fix is the same shape as elsewhere — constrain the credential-issuing actions by which target principals they may name, and keep that set free of anything stronger than the issuer.
go deeper
Remember that a credential proves who you are and a permission says what you may do. Being able to create a credential for somebody else means being able to act as them.
Explain that this class changes only authentication material, so no permission document changes, and name the verbs: issuing a static credential, resetting a login secret, registering a factor, binding a key.
Show the operational consequence: a clean permission diff proves nothing here, the record attributes later actions to the target principal, and the control is constraining which target principals the issuing actions may name.
Decide where the issuing function sits in the organisation. Wherever the platform bundles credential management into one action, accept that the group holding it is an administrative function and staff and review it as one.
## Authentication material is not authorization, and that is the problem A platform's access model has two halves. Authorization decides what a principal may do and lives in permission documents. Authentication material — a long-lived static credential, a human principal's login secret, a registered second factor, a public key or certificate bound to an identity — decides **who gets to be that principal**. The escalation here never touches the first half. A grant to issue credentials reads like operational support work, because that is mostly what it is used for: somebody loses a factor, a pipeline needs a credential, a service account is rotated. The grant names an action about credentials and a resource that is a principal. It contains no administrative action, and it changes no permission. Its reach is nevertheless the union of everything the principals it may issue for are allowed to do. ## The verbs in this class - **Issue a long-lived static credential for another principal.** The most direct form: you now hold a working credential for an identity you do not own. - **Set or reset a human principal's login secret.** Same result through the interactive path, though a second factor you do not control may stand in the way. - **Register an additional authentication factor.** Where the platform lets you add a factor rather than only reset one, you have removed the obstacle above without needing the existing factor. - **Bind a new public key or certificate to an existing identity.** Nothing is reset, the legitimate holder notices nothing, and you can authenticate as that identity from then on. These are four spellings of one action: *make a new way to prove you are this principal*. ## What the grant set shows afterwards Nothing. That is the distinguishing feature of this path against the ones that rewrite documents. No allow was added, no document was attached, no trust condition changed. A reviewer diffing permission documents week over week sees a clean diff. What does exist is a record: the platform records the credential-issuing call as made by the support principal, and then records the subsequent actions as made by the **target** principal, because that is who authenticated. The two halves have to be joined by whoever reads the record, and the join is not obvious unless somebody is looking for it. ## Constraining it | Approach | What it buys | Residual | |---|---|---| | Limit the credential-issuing actions by the set of target principals they may name | The path exists only toward principals in that set | You must keep the set free of anything stronger than the issuer, including future additions | | Split the issuing function from the principals that hold management permissions | The strong identities are simply not issuable by this group | Somebody still issues for them, and that somebody inherits this analysis | | Prefer identities that receive credentials from the platform over ones with issuable static credentials | There is less material to mint | Human principals and outside integrations still need something | | Alert on a credential issued for a principal outside the issuer's normal set | Detection, and a usable signal because the action is rare | The credential already works by the time it fires | ## The reasoning to carry away When you review a grant set for escalation, sort the actions into the ones that change **what a principal may do** and the ones that change **who may be that principal**. Reviews are built around the first list and escalation lives in both. A grant with no authorization verbs in it at all can still be the strongest grant in the account, and this is the class where that is most often true — which is exactly why it is described as a permission that reads as read-only and is administrator in disguise. Platforms differ in how many of these verbs exist and how separable they are: some expose distinct actions for creating a static credential, resetting an interactive login and registering a factor, while others bundle credential management into one action, in which case you cannot grant the harmless part without the dangerous part. Where they are bundled, the honest answer is that the group holds the strongest reach in the set and must be treated as an administrative function.
- A review compares permission documents week over week and reports no change. Has it ruled this path out?No. This path changes no permission document, so a clean diff is the expected outcome. Ruling it out needs the credential-issuing actions themselves in scope: who may issue for whom, and whether any target principal outranks the issuer.
- Does requiring a second factor on the target principal stop this?It stops a bare secret reset, but only where the issuer cannot also register a factor. If the same grant covers adding an authentication factor, the requirement is satisfied by a factor the attacker enrolled. The control is only as strong as the narrowest verb in the grant.
- How would you tell this apart from ordinary support work after the fact?Join the issuing call to what the target principal did next. Routine work shows a credential issued and then used by its intended holder from their usual context; the escalation shows the new credential used immediately, from the issuer's context, for actions that principal does not normally perform.
saying these in an interview costs you the question
- Says a grant that changes no permission cannot escalate
- Treats credential issuing as helpdesk work rather than access
- Assumes a required second factor blocks it in every case
- Believes permission-document review would catch it
- Confuses who the credential is issued for with who controls it