"It's the [company name] + [year]." Stanislav Kazanov, head of strategic practices at Innowise, reports that was the embarrassed, whispered answer he received when he asked for the password protecting a spreadsheet that contained a company's most sensitive secrets.
Discovery on the SharePoint "DevOps_Handoff" folder
Kazanov found the file while performing compliance and data architecture audits for a fintech startup. He logged into the firm's SharePoint site and navigated to a company-wide intranet folder labeled "DevOps_Handoff" that, according to his account, any employee could access. Inside was an Excel spreadsheet with the conspicuous filename Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx.
The file: Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx and a usable password
The spreadsheet was password-protected, but the protection proved fragile. When Kazanov asked the lead engineer for the password, the engineer replied — awkwardly, with his eyes down — "It's the [company name] + [year]." The column that chronicled the episode suggested using "Contoso" as an illustrative placeholder; that would yield a password like contoso2026. The implication in Kazanov's account is that the actual protection was trivial to guess because it followed an obvious company-name-and-year pattern.
What was inside: root DB credentials and master AWS IAM keys
The contents were not test data or low-privilege tokens. Kazanov reports the spreadsheet contained root database credentials and master AWS IAM keys. Those credentials had been placed in the file as a temporary workaround after an internal dispute: the internal DevOps team and an external DBA team could not agree on which enterprise-grade password manager to adopt. To "temporarily" resolve the disagreement, the teams dumped shared, high-privilege secrets into the spreadsheet. According to Kazanov, that file had existed on the intranet for eight months at the time he found it.
Contrast: "military grade" security and a spreadsheet on an intranet
The fintech startup had, by the account Kazanov provided, invested more than $1 million to develop a "military grade" security posture that included biometric multi-factor authentication, endpoint detection, and substantial physical security measures. Yet those investments sat alongside a single, broadly accessible Excel file that centralized root credentials. The PWNED column that reported the episode underscored the mismatch with a series of wry bullets: "- The company's biggest security hole lived in the breakroom" and "- Sticky-note security turned gym into hall of '80s horrors," illustrating the gulf between advertised controls and the operational shortcuts documented in the audit.
What this means for DevOps teams, procurement leaders, and fintech customers
- DevOps teams and contractors: The account lays bare the operational risk when temporary workarounds become long-lived fixtures. The decision to centralize root credentials in an accessible spreadsheet — the product of a procurement impasse — created a single point of failure that persisted for months.
- Procurement leaders and executives: The episode shows how vendor or tool-selection disputes can cascade into insecure interim practices. According to Kazanov, the conflict over which enterprise password manager to use directly produced the spreadsheet workaround; that disagreement should have been settled within the teams responsible for credential stewardship.
- Fintech customers and the public: The report notes the company was a fintech firm and warns that data involved could have related to "millions or even billions of dollars" of people's money. The presence of root database and master cloud keys in an accessible file represents a failure point with potential systemic exposure.
Kazanov's report says he raised the problem; the column concludes with the assumption that the issue was remedied "after Kazanov's intervention and before tragedy struck." The story, as recorded, leaves that follow-up unverified but makes clear how a small, administrative compromise — a shared spreadsheet, a predictable password, a months-long "temporary" fix — can override the protections that high-budget security programs are supposed to provide.
It is a terse lesson: security investments and controls mean little if operational decisions and interpersonal disputes push secrets into the one place every employee can find them. The spreadsheet's filename did not keep secrets secret; the password did not keep the password safe. What remains is a simple, persistent question the account raises for any organization handling large sums or sensitive data: who, ultimately, decides how credentials are stored and who enforces that decision?
