What Practitioners Actually Think About Identity and Passwords

Where this comes from

Cloud Security Office Hours is a free, open Zoom that runs every Friday. Practitioners drop in, someone asks a question, the room works through it, and every session gets a published recap. Identity runs through most security conversations, so it is mentioned in passing in many recaps. This page draws on the twenty-two where it was worked through, from April 2024 to September 2026, including a January 2025 guest talk on tracing an attacker through chained AWS roles and a May 2025 session that took up password complexity charts.

This is not a survey and not a consensus document. It is what people said to peers rather than to a camera. No attendee is named apart from guests who presented publicly. Where sessions contradicted each other, both views are here. The site's IAM and cloud identity page and its non-human identity page cover the mechanics; this page covers what practitioners said to each other about them.

Unique beats complex

The clearest statement came in the May 16, 2025 session, when the discussion turned to password complexity charts. One member argued that such charts are outdated because they do not address the threats that matter now, such as credential theft, phishing and online attacks, and that a password's uniqueness matters more than its complexity. The conversation moved on to two-factor authentication, passkeys and federated authentication, and to how hard secure authentication is to get right for enterprise and consumer users alike. Password managers and adaptive authentication policies were suggested as part of the answer.

The same argument came back in the February 27, 2026 session: long, complex passwords offer limited protection compared with unique passwords and MFA. Complexity rules and regular rotation are still widely recommended, but the point made was that MFA gives much stronger protection in practice than any complexity requirement, and that the aim should be several barriers to compromise rather than one strong secret. The session also noted a study finding that AI-generated passwords can be easily predicted.

Rules that look strict without protecting much drew frustration. In the June 13, 2025 session the example was requiring special characters in passwords on systems that do not properly sanitize their input. The April 17, 2026 session took up a report that HSBC India was requiring customers to enter their passwords in all capitals. The requirement raised the suspicion that passwords were stored in plain text, and one member explained why proper storage uses one-way cryptographic hashing instead. The group debated whether the bank might have been converting passwords to uppercase before hashing, which would explain why existing passwords only worked in capitals, and whether the change pointed to a security problem or a database migration issue. Participants also questioned whether the message was genuine or a phishing attempt, and another member pointed out that the post was dated April 1 and might have been a prank.

Password managers were treated as the practical answer, with one open question. The June 26, 2026 session compared Bitwarden, Dashlane and 1Password, and one member described moving a 75-year-old relative from LastPass to Bitwarden, a reminder that usability is part of the threat model. In the September 4, 2026 session, a member described using 1Password's Watchtower feature to watch for breaches across several unique email addresses. Whether the same manager should also hold MFA codes is one of the open questions below.

The second factor, and who gets exempted

MFA was treated as the baseline, and the sessions dwelt on the cases where it is awkward. The August 30, 2024 session began with one member's trouble using two-factor authentication on AWS in Firefox and moved to MFA for shared accounts in small and medium-sized businesses. The group agreed this needs a robust approach, and the suggestions included a FIDO key for each person who has the shared access. For root accounts, one member suggested splitting the task into three parts, which raised the question of whether that works in medium and large organizations. Managing and protecting SIM cards came up in the same discussion. Later in the session, another member described using physical safes for key security.

Against a named adversary, the advice was specific. In the June 20, 2025 session, a member who had seen Scattered Spider target infrastructure in a previous incident recommended FIDO authentication, device trust, and out-of-band communication, and another stressed zero trust and supply chain security. The group added limiting user access and securing document sharing, while one attendee pointed out that organizational resistance makes these practices hard to put in place. The site's Scattered Spider / MGM kill chain shows how the group gets in.

Missing MFA was named as a root cause more than once. In the September 4, 2026 session, two members said that in the customer organizations they see, many compromises come from simple gaps like missing multi-factor authentication rather than from sophisticated attacks. Another argued that security failures come mainly from people, organization, budget and priorities rather than from a lack of tools. The same session discussed a reported breach of well over a hundred million US driver's licenses offered for sale, and a story shared from Reddit about a bank account that was taken over after the owner's driver's license passed validation.

The August 28, 2026 guest talk by Stryker made the same point from the program side. One of the biases she sees when consulting is an appetite for new controls over old fights, when MFA, credential rotation and session token handling would address much of the exposure. Her recommendations for executives included hands-on help installing a password manager, followed by MFA that is actually enforced. The prompt for that last point was a public post describing an IT team that answered an executive's trouble with an authenticator app by creating a group that exempted them from MFA entirely. The human risk digest covers the rest of that talk.

Sessions, re-authentication and leavers

How often to make people sign in again came up in the June 13, 2025 session. One member shared an article from Tailscale arguing that frequent re-authentication often solves the wrong security problem and is more annoying than protective. Two members pointed to Apple's approach of using device possession and attention as a way to add assurance without interrupting people. The same session discussed complex password policies, session expiration and federated authentication, with frustration at restrictive measures that often fail to provide real security.

The other end of a session is the moment access should stop. In the same session, one member noted that some enterprise platforms can leave access open for up to 30 days after an account is deactivated. The November 29, 2024 session covered the wider problem of removing someone's access from many systems after they leave, alongside experiences of finding default passwords still set on firewalls.

Least privilege at cloud scale

The fullest IAM discussion was in the March 28, 2025 session, which began with a member asking why customers still struggle with identity and access management when so many tools exist. One answer was that the move to cloud put velocity and efficiency ahead of security. Another was that the problem has grown too large for humans to handle and needs technology to solve it. Two members described how hard it is to decide what permissions a role needs, and the role sprawl that follows; two others stressed least privilege for the services that run, not only for people.

The same session put the scale problem plainly. Cloud providers publish least-privilege role examples, one member noted, but implementing them at scale is complex, and another described customers who granted broad access to deploy quickly and then struggled to reduce it. A third told the story of a service account with excessive permissions that led to a major security incident.

Identity as the perimeter came up in the February 7, 2025 session, over how to secure several Microsoft cloud products and other SaaS platforms together. One member's approach was to use as few of those platforms as possible. Another stressed centralized identity providers and governance guardrails, and described identity management as a matter of people, process and technology. Two members also discussed role-based access control as a way to limit the blast radius of sensitive information, and the group discussed insider threats in the context of cloud security platforms, which led to a suggestion for a future session on securing posture management tools.

The June 12, 2026 session turned to conditional access. One member explained how it can gate access on location, time and device state, and another emphasized matching the strength of the control to the sensitivity of what is being accessed. The group treated CASB and SASE as complementary layers for governing access to cloud and SaaS, and earlier in the session had listed conditional access through the identity provider among the layered controls for protecting GitHub repositories.

Kubernetes adds its own layer. In the April 25, 2025 session, discussing an article on how pods inherit permissions, one member argued that the move to smaller, team-specific clusters has made traditional Kubernetes role-based access control less critical for many organizations, and that the article's more significant point was the potential for a pod to escape the cluster and reach the wider cloud environment. Another had previously focused on blocking access to the metadata service without realizing the full implications.

Secrets and service accounts

The April 26, 2024 session was about managing and safeguarding secrets, with the emphasis on malicious insiders and the misuse of tools like the AWS and Google command-line interfaces. The strategies discussed were canary tokens to detect unauthorized access, monitoring S3 bucket names, and proactively auditing environment variables and secrets, along with the risk of storing secrets in code. One member made the case for strong passwords with an incident involving a deputy CISO.

The November 29, 2024 session, on AI services in the cloud, found the same problem in new places. One member pointed out that many organizations have exposed access keys to AI services, and that secrets in Git commit history need a plan to remove them.

In the April 25, 2025 session, one member argued that the bigger risk in container environments is how engineering teams deploy code, and specifically how they mishandle secrets and credentials, and stressed proper secrets management, rotation and least-privilege access for container workloads. The same member offered to share a list of where secrets are commonly found. Another expressed frustration at how little progress has been made on developers mishandling credentials, and a third suggested a "secure operations lifecycle" to complement the secure development lifecycle.

Service accounts brought the question down to a single alert. In the November 1, 2024 session, a security operations engineer asked about an alert for a Kubernetes controller able to read secrets and pods. The advice was to evaluate whether those permissions were needed and whether the third-party service was misconfigured: the alert might reflect a valid configuration, but limiting the service account to reading only its own secrets could be preferable, and more triage was needed before deciding. With the engineering team disputing the alert, the engineer was advised to learn more about Kubernetes, reproduce the alert in a development environment, and work out how business-critical the system was.

When the identity system is the target

Two sessions dealt with attacks on the systems that issue identities. In the April 5, 2024 session, one member walked through the previous year's incident in which a Chinese actor obtained a Microsoft signing key used for authentication. The member pointed out that Microsoft's initial explanation of where the key came from had turned out to be untrue and that the exact method was still unknown, and saw it as marking a decline in Microsoft's security from a peak in 2014, which the member attributed to a lack of transparency and accountability in how the company handled the incident. The same member credited the company's software engineering but said its operational security and engineering needed to improve. The site's Storm-0558 kill chain sets out what is known.

The March 28, 2025 session covered reports of a breach in Oracle Cloud's authentication infrastructure. A threat actor claimed to have taken data, and some customers had confirmed that the leaked information was authentic. Despite Oracle's denials, one member advised rotating credentials as a precaution, and the group stressed credential rotation and the need to be familiar with the process. The group also agreed that the word "breach" should be used with care, and one member saw a possible shift in cybercrime from ransomware as a service toward stealing credentials and selling data.

Following an identity through the logs

The most technical session on this page was the January 3, 2025 guest talk by Itay Haral on cloud detection engineering, which centered on role unchaining in AWS. When a user assumes one role after another, the identity of the original actor is obscured, so a SOC tracing an incident has to work back through the chain to find who started it. The talk distinguished drive-by attackers, who are noisy and easy to detect, from more sophisticated ones who use role chaining to hide.

Temporary access keys looked like the obvious breadcrumb, but console sessions generate almost random temporary keys, and console activity can avoid being logged against the relevant key, although attackers mostly use the console for reconnaissance rather than to hide. The breadcrumb that worked was an identity tuple of session name, role name and session creation date, which held up across accounts within an organization. External identity providers such as Okta make unchaining simpler, because they restrict some of the actions attackers would otherwise exploit. Asked about tracking actors across providers, the speaker rated Google Cloud easiest, then AWS, then Azure, and another member agreed that even Microsoft struggles with Azure. The recording is on the presentations page.

Sign-in logs came up as detection data in the August 7, 2026 session, when one member asked how to detect unsanctioned AI use with Microsoft Sentinel. One member advised checking that the right Microsoft logs are being collected, particularly non-interactive sign-in logs and managed identity sign-in logs, and creating specific alerts for shadow AI activity. The group also suggested device inventory, browser behavior and network egress controls.

Agents are identities now

The newest identities in these sessions belong to AI agents. In the April 3, 2026 session, asked how user privileges work in AI systems, one member described the current implementation, built on service accounts and user delegation, and the challenges of dropping privileges. Another suggested defining atomic operations in an ontology along with the privileges each one requires, which the first member called a feasible approach that might involve temporary role assignments. The two also discussed revoking privileges on a time or task basis, just-in-time access, and least privilege.

In the June 5, 2026 session, one member presented Anthropic's white paper on agentic security, which treats non-determinism as a core risk and proposes tiered identity and access-control frameworks for agents. Two attendees felt it read more like positioning than prescriptive guidance, lacking concrete implementation detail and cryptographic controls, and questioned whether autonomous agents can be made reliably secure at organizational scale at all. The discussion widened to who owns agent security: the model provider or the infrastructure provider. The site's non-human identity page covers how agents get their credentials.

Where the room disagrees

These are live disagreements, not strawmen. None of them were settled.

Is zero trust a method or a slogan?

In the June 20, 2025 session, one attendee expressed concern that zero trust's theoretical appeal runs up against practical challenges. Another, from experience, called it a journey rather than a destination and contrasted security incidents at Microsoft and Cloudflare. A third, using the image of "Dyson syndrome" in change management, argued that making risks clearly visible is what gets people to act. In the September 25, 2026 session the argument was sharper: one attendee said zero trust has become a marketing term, overused the way AI is in product descriptions, and another countered that it was never a buzzword but complex guidance that takes significant planning and work to implement. The April 17, 2026 session had already named zero trust, with defense in depth and improved infrastructure, as a better answer to faster attacks than patching speed alone.

Should one vault hold passwords and MFA codes?

In the June 26, 2026 session, participants debated whether keeping credentials and MFA codes together in one password manager is a convenience or a risk. The recap does not record them settling it.

Is a container a security boundary?

In the April 25, 2025 session, one member warned that Kubernetes takes significant expertise to run securely and that container boundaries are not security boundaries, and recommended bulkhead isolation for sensitive workloads. Another replied that with good operational hygiene containers can come close to being a security boundary, but would still not mix high- and low-sensitivity workloads in the same cluster. A third wanted cloud providers to offer more secure defaults and better role management.

Can agents be secured at scale?

In the April 3, 2026 session, two members treated agent privileges as a hard but workable engineering problem, with answers ranging from an ontology of atomic operations to just-in-time access. In the June 5, 2026 session, the group debated whether a white paper on agent security offered practical guidance or mostly framing. Two attendees found it short on concrete implementation detail and cryptographic controls, and questioned whether autonomous agents can be made reliably secure at organizational scale at all.

FAQ

Is this an official position of Cloud Security Office Hours?

No. It is a synthesis of what attendees said on the live Friday call across twenty-two sessions. CSOH is vendor-neutral and takes no house position on any identity provider, password manager, or other product. Where attendees disagreed, both sides are reported rather than reconciled, and opinions are labeled as opinions.

Why are no individual attendees named?

The Friday session is open to anyone, but it is a conversation, not a publication. People think out loud, change their minds, and talk about their employers informally. Attributing opinions to named individuals would change what people are willing to say. Guest speakers whose talks are published on the presentations page are named, because presenting is a public act.

How were these sessions selected?

They are the recaps between April 2024 and September 2026 in which passwords, multi-factor authentication, cloud identity and access management, secrets and service accounts, or the identities given to AI agents were discussed in enough depth to draw on, rather than mentioned in passing. Every claim on this page links to the recap it came from, so any reader can check the source.

Does this page recommend a password manager or identity product?

No. One session compared several password managers, and products come up throughout because the recaps name them. This page reports what was said about them, not a verdict on which to buy.

Can I join the Friday session?

Yes. It runs every Friday, it is free, there is no pitch, and there is no requirement to speak. Details are on the sessions page, and every past session has a published recap.