Skip to content
Current/ Help Center

Petra Security: Microsoft 365 identity posture and account compromises

11 min read · Updated Sep 21, 2026

Petra Security is identity threat detection for Microsoft 365, built for MSPs. It watches a partner's Microsoft 365 audit trail for one thing: a real account compromise, an attacker actually inside somebody's mailbox. Around that it assesses 31 controls in how that Microsoft 365 is configured, scores the result out of 100, and counts the sign-in attacks that were tried and failed. This connector reads all three onto the matching Current company, so they reach the company record, your business reviews, your roadmaps and the company alert band. Current reads Petra and can never change anything in it.

SCREENSHOT — coming soon
Integrations → Petra Security: the connection card once a key is in, with the sync cadence and what it feeds.
Note
What this connector is for
It is a reporting feed, not a console. Petra's public API has no write address of any kind: every address in it is a read. So Current cannot lock an account, revoke a session, retract a phishing email, apply a posture fix, unpause a tenant or edit a report, and no bug in Current can reach those actions because there is nothing to reach. They live in the Petra dashboard, and that is where you take them. Current routes every call through a read-only allowlist anyway, so the guarantee holds if Petra ever adds a write address.

What Current syncs

Data setWhat Current storesWhere it lands
TenantsEach Petra tenant by its Petra id and name, its Microsoft 365 directory id, whether it is paused, and the date it was onboarded.The mapping panel on the Petra Security card
Licensing and servicePer tenant: how many users are licensed, whether Petra is monitoring the tenant or has only scanned it, and the billing state Petra holds for it. The billing figures are about your own Petra account.The Petra card on the company record, and the coverage line in its header. Never a business review
Account compromisesPer incident: when it happened, when Petra recorded it, whether an attacker is still in the account, how far the clean-up has got, an estimate of how long the attacker had, the compromised account's name and sign-in address, and the phishing email's subject, sender and where that mail sits now. How many other mailboxes received the same phish is kept as a count.The account compromises section of the Petra card, and the identity-compromise alert
Posture reportsPer tenant, the newest completed assessment: the score out of 100 and the grade Petra gave it, the score before it on a follow-up, how many controls were assessed, met, open, drifted, in progress or not assessed, and when it completed.The posture figures on the Petra card, the Microsoft 365 story in a business review, and a dashboard tile
The 31 controlsPer control on that report: its name and category, whether it is secure, fixed, open, drifted, in progress or not assessed, the severity Petra rates it, the plain-English current state, why it matters and the fix Petra wrote for it.What is open on the Petra card, the critical-control alert, and the Suggested tray on a roadmap
Global administratorsPer report: how many global administrators the tenant has, how many Petra counts as signing in with strong MFA, the maximum Petra recommends, how many carry a password old enough to flag, and whether Microsoft returned the full list.The global administrators section of the Petra card, and the People posture on the company record
Failed attacksOne rolling 30-day window per tenant: how many sign-in attacks failed, the countries they came from, and up to five of the most-targeted people. Petra's own attack codenames are stored exactly as sent and grouped into families a person recognises before anything is drawn.Attacks stopped on the Petra card, and the attack volume in a business review
Note
What Current stores about people, and what it leaves behind
Petra's data is about people, so the line is drawn deliberately. Current keeps the compromised account's name and sign-in address and the phishing email's subject, because a technician cannot act on "somebody was breached". Those are staff-only: a Partner Viewer is blocked from them at the database rather than hidden from them in the interface, they never enter an AI prompt, and they never appear in a business review a partner's client reads. Petra ships its own Anonymize Incidents feature for the same reason. A pack gets the counts, the score, the control gaps and the attack volume, and the named person stays inside Current on the company page. Current also leaves fields behind at the source: the Graph object id, the mailbox address that repeats the sign-in address and the password clock on a compromised account, the mail-routing fields on a phishing email, and the list of every other mailbox that received the same phish, which is kept as a count rather than a list. And Current never calls Petra's billable-users address at all, because that would mirror a named list of every licensed employee of every partner to learn a headcount the licensing read already returns in one request.

Create the API key in Petra

A Petra API key belongs to the whole Petra organization, which is your MSP, so one key reaches every tenant you manage and there is nothing to paste per tenant. Petra has no read-only scope on a key, because a key inherits the organization rather than a role. That is why Current's read-only guarantee comes from the API having no write address rather than from a narrower key: there is no narrower key to ask for.

  1. 1
    1 · Sign in at app.petrasecurity.com as an Admin
    Petra's Admin role is the only one that can create or delete an API key. A Full Member can open the key list and see that keys exist, but never sees a value and gets no Create button; the Sales and External Guest roles cannot reach the page at all. So a missing Create button is your role, not a fault. Ask a Petra Admin to make the key.
  2. 2
    2 · Open Settings, then API Keys
    The page lists the keys the organization already has. Nothing here is per tenant.
  3. 3
    3 · Press Create API Key
    Describe it with something a colleague will recognise, such as Current, so a future admin can tell which key belongs to what.
  4. 4
    4 · Copy the key now
    Petra shows the full value once and can never show it again. If the page closes before you copy it, delete that key and create another. Petra publishes no expiry on a key, so it keeps working until somebody deletes it, and a deletion takes effect at once.

Connect it in Current

  1. 1
    Open the Petra Security card
    In Current's left menu open Integrations (it sits under Workspace, so Tenant Admins have the link) and find Petra Security in the Monitoring & security section.
  2. 2
    Paste the key and press Test connection
    Paste it into API key. Current reads your tenant list to prove the key works, then stores it server-side only: the browser never sees it again, and it is never written into a web address, a status message or a log. There is nothing else to fill in, because Petra has one global address with no regions, so the class of bug where a wrong region reads as a bad key cannot happen here. Current does not check the petra_ prefix either: a prefix Petra changed later would turn every new key into "invalid" with no way for an admin to tell why, so Petra's own answer is the only judge of a key.
  3. 3
    Map Petra tenants to your companies
    The first sync reads your tenant list before anything else, so the mapping panel fills straight away. Each Petra tenant is one end-customer. Current matches on the normalized company name (lowercased, with punctuation and Inc/LLC/Ltd-style suffixes stripped) and links it when exactly one company matches; a name that fits two waits on the Unmapped tab for you to decide rather than being paired on a guess. Mapping one by hand attaches its posture, compromises and attacks right away instead of waiting for the next six-hourly sync. The Petra tenant id is the one in the dashboard address (app.petrasecurity.com/tenant/…), so an unmapped row is one click to check. Petra also sends each tenant's Microsoft 365 directory id, which Current stores but does not match on, because a workspace that has not connected Microsoft 365 would have nothing to match it against.

How often it syncs

Petra syncs every 6 hours on a schedule, plus whenever a Tenant Admin presses Sync now on the card. Each run reads your tenants, then the licensing figures, then the account compromises, then the posture reports, then the failed attacks for a share of your tenants. Petra allows 10 requests a minute on each address, which is the tightest allowance of any connector in Current, so runs are paced under it and Sync now waits 10 minutes after the last run. The message says how many minutes are left.

The failed-attack read is the only one that asks per tenant, so each run takes a batch of them oldest-first and the next run continues where it stopped; every tenant comes round inside a week, and the window it reads is a rolling 30 days. The first run reads back 180 days of account compromises, and after that each run re-reads the last 14 days, which picks up an incident whose clean-up has moved on since. Nothing removes an account compromise once Current has it: Petra's incidents address returns the newest 500 and offers no way to reach the 501st, so keeping every one Current has ever seen is what makes the history grow instead of shrink. If a first run meets that ceiling, the card names the date its history starts rather than printing a count over a window nobody can state.

What "Not assessed" means

Petra scores 31 controls, and each comes back secure, fixed, open, drifted, in progress or not assessed. Not assessed means Petra is missing a Microsoft permission for that control, not that the setting is wrong. The usual reason is age: a Microsoft 365 tenant authorised in Petra before 17 July 2026 predates the permission set the posture assessment needs. Petra can grant the missing permission from its own Posture reports page, and the next assessment scores the control. Until then Current keeps it out of both halves of every share it prints and gives it a tile of its own on the card, because counting a missing permission as a failure invents a problem the partner does not have. Petra's own score does the same.

Two more readings travel with it. Secure and fixed both count as met, open and drifted both count as not met, and a control Petra has not ranked for severity is unranked rather than low, so it never enters the critical or high counts. And a compromise Petra marked as a pen test or as a false positive is left out of every count, rather than being read as unremediated because it is not marked remediated.

Where the data shows up

  • The Petra card on the company record: the posture score with Petra's grade and which way it moved since the baseline, the four control counts (met, open, drifted and not assessed), the critical and high controls that are open with what Petra says the state is, the account compromises with how far the clean-up has got, the global administrators against the maximum Petra recommends with the strong-MFA share and its denominator, and the sign-in attacks that failed in the last 30 days with where they came from. The header says whether Petra is monitoring the company, has only scanned it, or has it paused.
  • The People posture on the company record, where the licensed identities and the global administrators sit beside the rest of the people signals. Petra counts global administrators specifically, so those numbers stay separate from a workspace-wide MFA figure from Duo: the same person in two denominators would make both meaningless.
  • A Strategic Business Review, in the security chapter: the score and its direction since the baseline, how many controls have been fixed since then, the critical ones still open by name, and the attacks the tenant absorbed. No compromised account, no administrator, no phishing subject and none of Petra's attack codenames reach a pack.
  • The company AI brief, as one line of counts with the control names and severities. The compromised account, the phishing subject and the most-targeted people are kept out of what the AI is given rather than filtered afterwards.
  • Roadmaps: every open or drifted control Petra rates critical or high arrives in the Suggested tray carrying its own rationale and the fix Petra wrote for it. A company Petra has only scanned, where the scan turned something up, arrives as a finding too.
  • A Microsoft 365 posture dashboard tile, averaging the score across the companies with a completed assessment. A company without one sits outside both halves, and the tile says how many it covers.
  • The company alert band: an account compromise that is still open, which turns critical while an attacker is still inside the account, and a control Petra rates critical that is open or has drifted.
Note
The score itself raises no alert
Petra recommends a floor of 61 out of 100 and its own example tenant scores 52, so a rule on the score would open an alert on nearly every company in your workspace the day you connect, and an alert everybody has is an alert nobody reads. The score sits on the company card, in the business review and on the roadmap, where a 52 starts a conversation. The two alerts are kept for what is actionable now: a compromise still being cleaned up, and a critical control that is open or has drifted. A compromise Petra found in its six-month lookback and nobody has closed opens as a warning; one where an attacker is still in the account opens as critical.

When something looks wrong

What you seeWhat it means
Test connection says the key is invalidPetra refused it: the value was mistyped, or the key was deleted in the portal, which takes effect at once. Current shows Petra's own words. Create a fresh key under Settings, then API Keys, and paste the value from the dialog. Current never retries a refused key, because a refused request spends Petra's 10-a-minute allowance exactly like an accepted one.
Petra's edge refused the requestSomething in front of Petra's API turned the request away before it arrived, and answered with a web page instead of an API answer. Current says so rather than reading that page as an answer. It usually clears on the next run.
Fewer tenants than you have in PetraThe key belongs to a different Petra organization than the tenants you were expecting. A key covers the organization it was created in, so compare the count on the card with the tenant count in the portal.
A company shows no Petra dataIts Petra tenant is not mapped yet. Check the Unmapped tab on the card.
A tenant is listed, but Current skipped itPetra answered that the tenant is not in the key's organization or no longer exists, which usually means it was removed between the tenant list being read and its detail being read. Current records the skip, keeps that tenant's existing rows and carries on with the rest rather than failing the whole run.
The card says Paused in PetraThe tenant is paused in Petra, which is a choice somebody made. Petra still lists it, Current still shows what it has, and the card names the state instead of going quiet or reporting a fault.
Scanned, not monitoredEvery Petra tenant mapped to this company is on a one-off forensic scan rather than ongoing monitoring. A company with one monitored tenant and one scanned tenant reads as monitored, because it already buys the service.
No posture score yetPetra has not completed an assessment for that tenant. The section stays out rather than showing a zero.
Global administrator counts show a dashMicrosoft returned only part of the administrator list, so Petra marked the figures incomplete. Current shows them as unknown rather than printing a number that is too low.
The card says counts are floorsThe first run met Petra's ceiling of 500 account compromises inside its 180-day window, so the history starts at the date the card names. Later runs add to it and nothing is removed.
Current didn't recognize a value Petra sentPetra shipped a clean-up state, a control state, a severity or an attack type this build has not seen. It is stored exactly as sent and counted as unknown rather than folded into a healthy number, and the connection's diagnostics name it. Tell support which one and the rule is added; the counts correct themselves on the next sync without a re-sync.
Sync now says to waitPetra allows 10 requests a minute on each address, so Current waits 10 minutes between runs. The message says how many minutes are left.
Sync now says the workspace is display-onlyA demo workspace, or one whose billing is frozen, shows what is already stored and doesn't call Petra. Sync now leaves the connection as it is.
The card says Petra is disconnectedThe connection was disconnected. The card keeps showing the last numbers Petra sent, and says so; reconnect to bring them up to date.
Note
Who can do this, and disconnecting
Connecting, testing, Sync now, mapping and disconnecting are Tenant Admin actions. Disconnect stops the sync and skips your workspace on the six-hourly sweep, and every open Petra entry in a company's alert band clears at that moment; other alerts on the company stay as they are. Everything already pulled stays put, and the company card keeps showing it with a line saying Petra is disconnected and these are the last numbers it sent. Reconnecting resumes the sync but doesn't reopen a cleared entry: if a compromise is still open or a critical control is still not in place, the next complete sync opens a new one. Nothing is changed in Petra either way, because its API gives Current nothing to change. Partner (read-only) viewers never see any of this data, and that is blocked at the database rather than hidden in the interface.
Was this helpful?