Cloud Service Accounts Created in the Console Still Need Owners

Cloud service accounts created directly in a provider console often enter production without an identity-governance record. A developer can issue an Amazon Web Services IAM user, a Microsoft Azure service principal or a Google Cloud service account in minutes. The technical object exists. The business owner, purpose, review cycle and retirement path may not. Citadel Identity360 helps teams bring those console-created accounts under named ownership, grant review and an accountable close-out when the work ends.

Console creation is a joiner event that identity programmes often miss

Employee joiners usually start in HR and flow into identity governance. Cloud service accounts often start in a cloud console, an infrastructure-as-code run or a ticket to the platform team. If IGA only sees accounts that someone requested through its own forms, console-created principals remain outside the system of record.

That gap is narrower than a general non-human identity primer, and it is not a recap of vendor grouping for outside people. Astranova already covers the service account visibility problem, governing service accounts with other machine identities, a type-by-type non-human identity guide and third-party access grouped by vendor. This article asks a different question: once a cloud principal has been created in the tenant, how does it receive an owner and a lifecycle in IGA.

What console-created should mean here

Use a practical definition. A console-created cloud service account is a technical principal that can act in Amazon Web Services, Microsoft Azure or Google Cloud and was provisioned through the provider interface, a script, or a platform request, rather than as an outcome of an approved identity-governance joiner.

Typical forms include:

• IAM users, access keys and often IAM roles in Amazon Web Services
• App registrations, service principals and managed identities in Microsoft Azure
• Service accounts and keys in Google Cloud

The creation path is what matters, not the marketing name. A role assumed by a compute service still needs an owner and a purpose. So does a long-lived access key created so a laptop job can run overnight.

This post stays on those cloud principals and the keys that support them. It does not open an AI-agent discovery discussion or treat every non-human identity in the estate.

Why the bypass creates hidden access risk

A principal created to unblock a deadline is rarely given the same record as a human joiner. Common results include:

• No living owner, or an owner field that still points to a person who has left.
• Purpose recorded only in a chat thread or a ticket that later expires.
• Grants that were broadened to make the first test succeed and never reduced.
• A related principal in a second cloud that nobody connected to the same workload.
• Credentials copied into job configurations and left in place after the project ended.

These patterns are illustrative. They show why first principles for cloud service accounts start with ownership at intake, not with a longer list of technical controls that have no decision-maker.

First principle: every cloud principal needs a living owner

Assign an owner as part of bringing the account into the governed inventory, even if the cloud object already exists. The owner should be able to state the purpose, accept or revoke grants, respond to reviews and authorise retirement.

A platform engineer who can create the principal is not automatically the business owner. Platform contacts still matter for credentials and runtime health. The accountability question is who answers for the access the account holds.

When the owner leaves or changes team, treat that as a mover event for every cloud service account they sponsor. An account that remains attached to a disabled mailbox is already on the path to becoming an orphan.

If no owner can be named, do not treat the principal as settled production access. Use a short-dated interim owner from the platform team while sponsorship is resolved. Temporary ownership without an end date recreates the bypass.

First principle: record purpose, environment and related principals

An owned account still needs a purpose that a reviewer can test. “Used by the cloud team” is not a purpose. “Nightly export of operational events from the analytics account into the warehouse project” is.

Capture the environment (development, test or production) and any sibling principals that serve the same workload in another cloud. One business process can have an Amazon Web Services role and a Google Cloud service account that nobody has ever listed together. Intake should connect them under the same owner even when the provider objects remain separate.

Do not invent a shared grant set across clouds. Purpose can be shared. Authorisations must still be reviewed on their own paths.

First principle: prefer short-lived credentials, then govern the rest

AWS IAM security guidance asks organisations to prefer temporary credentials and IAM roles for workloads, and to rely on long-term access keys only where a use case still requires them. The same page notes that some tools and third-party clients may still need IAM user long-term access keys, and it recommends updating those keys when people leave and reviewing unused users, roles, permissions and credentials.

That provider advice is about authentication design. It does not replace enterprise ownership. The governance translation is:

• Prefer roles or other short-lived patterns when the workload can use them, and still assign an owner and a purpose to the role.
• Where long-lived keys remain, treat them as owned exceptions with reduced grants, a review cadence and a retirement or rotation plan.
• A secrets vault can store a key. It cannot, by itself, tell you who still stands behind the access.

Citadel Identity360 does not replace the cloud provider’s IAM service. It helps the organisation keep the owner, purpose, reviews and fulfilment evidence that consoles are not designed to hold as a business record.

First principle: grants should stay aligned to stated purpose

Console creation often starts with a broad managed policy so the first integration succeeds. The durable rule is narrower: grant the actions and resources the purpose requires, in the environment the purpose covers.

Path context matters more than the principal name. An account that can write to one landing location is a different risk from one that can read customer records or change identity policy. Review the effective path when the account first enters governance and again at each certification.

Follow approved reductions through to fulfilment. A decision that never reaches the cloud principal leaves the extra grant in place.

First principle: retirement is a leaver event, not a deleted console row

When the purpose ends, an accountable owner should approve removal of grants and credentials and include related keys or machine identities that existed only for that workload. Investigate dependencies first. Blind deletion can stop a quiet job that operations still needs. A short notice window, when risk allows it, then tracked fulfilment is safer than an outage or an account that never closes.

Record who decided, what was removed and when fulfilment completed. That trail helps produce evidence for later assurance sampling. If a successor workload needs similar access, create a new owned record rather than recycling the old principal and keys.

Bring existing console accounts into the governed inventory

Most estates already contain principals created before this discipline existed. A practical intake sequence is:

1. List candidate service accounts, keys, roles and service principals from the cloud teams that operate Amazon Web Services, Microsoft Azure and Google Cloud.
2. Attach a living owner and a testable purpose, or escalate until one exists.
3. Link related principals that serve the same workload across clouds.
4. Inspect grants and paths against that purpose; reduce what no longer fits.
5. Decide keep, contain pending an owner, or retire, then confirm fulfilment.

Do not wait for a perfect historical census before governing the next account you find. Likewise, do not treat every cloud role as an emergency. The work is triage under an owner, not mass deletion.

Unused or idle clues, when you have them, should come from the cloud or application operators who can interpret provider last-used data. Treat those signals as inputs to the owner’s decision. Do not imply a product-native unused-runtime detector made the call.

Standards context for account management

NIST SP 800-53 Rev. 5 account-management language (AC-2) expects organisations to define allowed account types, assign account managers, require approvals to create accounts, review accounts, and align account management with termination and transfer processes. The discussion notes that policies can include expiration dates or other factors that trigger disabling of accounts, and lists service accounts among example types. Console-created cloud service accounts belong in that model once they exist: they need a manager or sponsor, a review cycle and a disable trigger when the purpose ends. Least-privilege (AC-6) still applies to the authorisations they hold.

These sources support programme design. Citadel Identity360 supports the operating record and helps produce evidence of owners, reviews and fulfilled changes.

How the platform supports console-account ownership

Once a cloud service account is in the governed inventory, Citadel Identity360 supports the ownership loop:

• Ownership: an accountable owner sits on the account from intake through retirement.
• Purpose and relationship context: the record can keep the reason the account exists and show related access paths the owner must attest.
• Reviews: certifications present risk context so owners keep or revoke grants, with fulfilment tracked to completion.
• Related non-human identities: API keys and machine identities that exist only to support the account stay under the same ownership window.

If the principal was created for an external firm, vendor grouping remains available as already described in the third-party access article. It is a complement, not the subject of this piece.

The platform supports decisions. It does not replace cloud IAM policy or the owner’s judgement about purpose.

An illustrative intake path

A reporting developer creates an IAM user in the Amazon Web Services console so a weekend extract can land files in object storage. The same workload later gains a Google Cloud service account for warehouse loads, created by a different engineer. Neither object has an IGA owner. Nine months on, both credentials still work. The developer has moved to another unit. Storage grants were widened during a failed test and never reduced.

Intake brings both principals into Citadel Identity360 under the analytics operations owner. Review keeps a narrowed write path to the landing location, removes the extra storage grant, and records the two principals as one workload. When the extract is later replaced by a pipeline that can assume a role, the owner retires the IAM user and its key and reviews whether the Google Cloud service account still has a purpose.

The story is illustrative. It shows late intake, owner assignment, cross-cloud linkage, grant reduction and retirement. The trigger was an owner change and a purpose review, not a claimed unused-runtime score.

Operating cadence that catches the next bypass

1. Require an IGA record, not only a cloud object, before a principal is accepted as production access.
2. Run a periodic intake with cloud platform teams for accounts created outside IGA request flows.
3. Sync human mover and leaver events to the cloud service accounts those people own.
4. Prefer short-lived credentials when the workload can use them; treat long-lived keys as owned exceptions.
5. Confirm fulfilment after keep or retire decisions, including related keys.

Keep a short RACI so the business owner, identity team and cloud platform team each have a job. Ambiguous ownership is how console-created accounts remain invisible after the original engineer moves on.

Questions raised by console-created cloud accounts

If a pipeline creates the account, is IGA still required?

No. Automation can create the principal consistently. It does not, by itself, assign a living business owner, present reviews or record fulfilment when the purpose ends. Treat pipeline-created accounts the same way you treat console-created ones: they still need a governance record.

Are managed identities and assumed roles in scope?

Yes, if they hold durable authorisations in the tenant. Short-lived session credentials do not cancel ownership of the role or identity that can obtain them.

Who should own an account the platform team created for an application?

The owner of the application or data process, not only the engineer who clicked create. Use a short-dated platform owner only while that person is identified.

Can last-used data from the cloud provider replace an access review?

It can inform the review. An unused clue is not automatic delete authority, and seasonal jobs can look idle between cycles. The owner still attests purpose and grants.

What belongs in a product demonstration?

Take one console-created cloud service account that has no living owner or still holds grants for a finished job. Assign the owner in Citadel Identity360, reduce or retire the access, and show the fulfilment trail. Request Demo after you pick the candidate, or preview the product on the videos page.

Start with one console-created account and a living owner

Choose one service account already sitting in Amazon Web Services, Microsoft Azure or Google Cloud that was created outside your IGA request flow. Bring it into Citadel Identity360 with a living owner and a testable purpose, then complete the review or retirement that record requires. Request Demo. Use the videos page as a preview before you select the account.