Multi-Tenant Microsoft 365 Evidence Integration (Graph + GDAP)
Budget: $10,000 – $20,000 USD
Feature Brief: Microsoft 365 Security Evidence (Graph + GDAP)
Overview
This project relates to an MSP-focused SaaS platform used across multiple customer tenants. The platform already supports multi-tenant workflows, customer management, integrations, and reporting capabilities.
This feature introduces a Microsoft 365 Security Evidence module designed to enhance existing functionality by automatically collecting lightweight Microsoft 365 security evidence through Microsoft Graph and GDAP.
The goal is not to create a Microsoft administration portal, Secure Score clone, or detailed Microsoft security dashboard. The objective is to collect high-value Microsoft 365 evidence that helps reduce manual effort and support security-related assessments while allowing users to retain full control over final decisions.
The feature should use Microsoft Partner Center and GDAP (Granular Delegated Admin Privileges) to allow an MSP to authenticate once and securely access delegated customer tenants.
The workflow should support:
- MSP Microsoft connection
- Delegated customer tenant discovery
- Tenant-to-client mapping
- Scheduled evidence synchronisation
- Evidence normalisation
- Integration into Security Findings
- Future scalability
Feature Name
Microsoft 365 Security Evidence
Purpose
The purpose of this feature is to:
- Reduce manual assessment effort
- Improve recurring review accuracy
- Strengthen report evidence
- Improve AI-generated content quality
- Increase confidence in findings
- Strengthen platform stickiness
- Support historical continuity
The feature should provide evidence only.
Final status decisions must remain with MSP users.
User Permissions
Microsoft connection management available to:
- MSP Admin
Not available to:
- Basic users
- Read-Only users
Evidence visibility within reports and findings may follow normal platform permissions.
High-Level Workflow
MSP Admin
-> Connect Microsoft 365
-> Authenticate using Microsoft Partner Center + GDAP
-> Discover delegated customer tenants
-> Map discovered tenants to internal clients
-> Scheduled evidence synchronisation
-> Evidence normalised
-> Evidence posted to internal API
-> Security Findings updated
-> Reports and AI content enhanced
-> MSP confirms final findings
Evidence Scope
It should intentionally remain lightweight.
Identity & Access
Collect:
- Multi-Factor Authentication presence
- Privileged account protection
- Security Defaults status
- Conditional Access presence
- Guest user count
Email Security
Collect:
- Safe Links enabled status
- Safe Attachments enabled status
- Anti-phishing protection status
Device Evidence
Collect:
- Intune presence
- High-level device compliance indicators
Exclusions
Do NOT include:
- Access log ingestion
- User activity reporting
- Raw audit logs
- Full Secure Score dashboards
- Data Loss Prevention policies
- Retention policies
- Collaboration security settings
- External sharing analysis
- Raw Conditional Access exports
- Mailbox information
- Device inventories
- Microsoft administration functionality
Placement
MSP Portal
Add:
- Microsoft 365 Security Evidence
Suggested location:
Settings > Data & Integrations
Connection Management
The platform should allow MSP Admins to manage Microsoft connectivity.
Required actions:
- Connect Microsoft 365
- Reconnect Microsoft 365
- Disconnect Microsoft 365
- Sync Now
Display:
Status:
Connected via GDAP
Last Sync:
22 August 2026 14:02
Last Successful Sync:
22 August 2026 14:02
Actions:
- Sync Now
- Reconnect
- Disconnect
Authentication Requirements
Use:
- Microsoft Entra ID
- Microsoft Partner Center
- GDAP
Requirements:
- MSP authenticates once
- Customer tenants discovered automatically
- Delegated permissions respected
- Support consent handling
- Support permission revocation
- Support token refresh
Tenant Discovery
Requirements:
- Discover delegated customer tenants
- Respect GDAP role assignments
- Retrieve tenant information
- Maintain tenant relationship information
Tenant Mapping
Each Microsoft tenant must map to an internal client.
Mapping should use:
- Internal Client GUID
If no mapping exists:
Display:
Unmapped Microsoft Tenant Detected
Tenant:
Northbridge Logistics Ltd
Actions:
- Map Existing Client
- Create New Client
- Ignore
Do not automatically assign tenants.
Sync Behaviour
Default schedule:
Automatic synchronisation every 24 hours
Support:
- Scheduled sync
- Manual sync
Rules:
- Manual sync should not bypass throttling protections
Display:
Last Synced:
22 August 2026 14:02
Evidence Processing
Collected Microsoft evidence should be:
- Simplified
- Normalised
- Mapped into internal schema
- Posted into /v1/security-evidence
Raw Microsoft responses should not be surfaced directly.
Security Findings Integration
Evidence should support findings only.
Evidence must not determine final status automatically.
Example:
Multi-Factor Authentication
Suggested Status:
Partially Deployed
Evidence:
- MFA detected for administrator accounts
- MFA not detected for all users
Confidence:
High
Last Synced:
22 August 2026 14:02
MSP Action:
Confirm Final Status
AI Integration
AI may use Microsoft evidence as supporting context.
AI should:
- Improve Executive Summaries
- Improve recommendations
- Improve What's Changed narratives
AI must not:
- Independently determine security conclusions
- Override MSP decisions
Development Ownership & Collaboration
This project will be delivered alongside an existing development team.
The Microsoft specialist is expected to own Microsoft-specific functionality only.
Microsoft Specialist Ownership
Responsible for:
- Microsoft Entra configuration
- Microsoft Graph implementation
- Partner Center integration
- GDAP implementation
- Authentication flows
- Consent handling
- Token lifecycle management
- Delegated tenant discovery
- Evidence collection
- Evidence normalisation
- Microsoft technical documentation
Existing Development Team Ownership
Responsible for:
- Frontend implementation
- Database structure
- Existing API integration
- Security Findings integration
- Report integration
- Activity Log integration
- AI integration
- Deployment
- Testing
- UAT
Integration Approach
Microsoft functionality should operate as a modular service.
Service output:
/v1/security-evidence
Existing platform components will consume the data.
The implementation should:
- Minimise changes to existing architecture
- Avoid tightly coupling Microsoft-specific functionality to core platform logic
Security & Data Handling
Requirements:
- Minimise stored Microsoft data
- Do not store raw Microsoft responses unless required
- Store only normalised evidence
- Encrypt refresh tokens
- Encrypt sensitive credentials
- Use HTTPS/TLS
- Support key rotation
- Support permission revocation
- Support token invalidation
Error Handling
Must support:
- Retry logic
- Throttling awareness
- Token expiry handling
- Consent failures
- Permission failures
- Sync failures
- Tenant discovery failures
Provide:
- Granular technical logging
- User-friendly messages
Activity History
Record meaningful Microsoft events only:
- Microsoft connection created
- Microsoft connection removed
- Tenant mapping created
- Evidence sync completed
- Evidence sync failed
Do not record:
- Individual API calls
- Token refreshes
- Low-level system activity
Future Expansion
Architecture should support future evidence additions without redesign.
Future examples:
- Secure Score indicators
- Defender posture signals
- Identity risk signals
- Device posture signals
V1 should remain limited to the defined lightweight evidence scope.
Deliverables
Source code with clear project structure
Preferred:
- .NET
- Node.js
- Setup scripts and concise README
Requirements:
- Development environment setup in under 30 minutes
- Test harness demonstrating:
- Delegated tenant discovery
- Tenant-to-client mapping
- Evidence collection
- Evidence normalisation
- Successful evidence posting
- Technical handover documentation including:
- Graph permissions used
- Entra ID configuration
- Partner Center configuration
- GDAP requirements
- Token handling approach
- Consent handling
- Retry strategy
- Error handling approach
Acceptance Criteria
Successful execution within staging environment demonstrating:
- MSP authentication using Partner Center + GDAP
- Delegated customer tenant discovery
- Tenant mapping
- Evidence collection
- Evidence normalisation
- Successful posting to /v1/security-evidence
- Scheduled synchronisation
- No manual intervention required after initial setup
UAT Scenarios
UAT-MG-001
Scenario:
MSP connects Microsoft using GDAP
Expected Result:
Delegated customer tenants discovered successfully
UAT-MG-002
Scenario:
Tenant discovered without mapping
Expected Result:
Tenant displayed as unmapped
UAT-MG-003
Scenario:
Manual sync initiated
Expected Result:
Evidence synchronises successfully
UAT-MG-004
Scenario:
Microsoft permissions revoked
Expected Result:
Connection status changes and sync stops
UAT-MG-005
Scenario:
Graph throttling encountered
Expected Result:
Retry logic executes successfully
UAT-MG-006
Scenario:
Evidence displayed within Security Findings
Expected Result:
Suggested evidence shown correctly with MSP override available
Development Handover Requirements
The implementation must be written & documented so that an existing development team can fully maintain & extend the functionality without requiring ongoing involvement from the Microsoft specialist.
Required:
- clear code structure
- inline documentation
- setup documentation
- permission documentation
- architecture overview
- deployment instructions
- guidance for adding future evidence types
Overview
This project relates to an MSP-focused SaaS platform used across multiple customer tenants. The platform already supports multi-tenant workflows, customer management, integrations, and reporting capabilities.
This feature introduces a Microsoft 365 Security Evidence module designed to enhance existing functionality by automatically collecting lightweight Microsoft 365 security evidence through Microsoft Graph and GDAP.
The goal is not to create a Microsoft administration portal, Secure Score clone, or detailed Microsoft security dashboard. The objective is to collect high-value Microsoft 365 evidence that helps reduce manual effort and support security-related assessments while allowing users to retain full control over final decisions.
The feature should use Microsoft Partner Center and GDAP (Granular Delegated Admin Privileges) to allow an MSP to authenticate once and securely access delegated customer tenants.
The workflow should support:
- MSP Microsoft connection
- Delegated customer tenant discovery
- Tenant-to-client mapping
- Scheduled evidence synchronisation
- Evidence normalisation
- Integration into Security Findings
- Future scalability
Feature Name
Microsoft 365 Security Evidence
Purpose
The purpose of this feature is to:
- Reduce manual assessment effort
- Improve recurring review accuracy
- Strengthen report evidence
- Improve AI-generated content quality
- Increase confidence in findings
- Strengthen platform stickiness
- Support historical continuity
The feature should provide evidence only.
Final status decisions must remain with MSP users.
User Permissions
Microsoft connection management available to:
- MSP Admin
Not available to:
- Basic users
- Read-Only users
Evidence visibility within reports and findings may follow normal platform permissions.
High-Level Workflow
MSP Admin
-> Connect Microsoft 365
-> Authenticate using Microsoft Partner Center + GDAP
-> Discover delegated customer tenants
-> Map discovered tenants to internal clients
-> Scheduled evidence synchronisation
-> Evidence normalised
-> Evidence posted to internal API
-> Security Findings updated
-> Reports and AI content enhanced
-> MSP confirms final findings
Evidence Scope
It should intentionally remain lightweight.
Identity & Access
Collect:
- Multi-Factor Authentication presence
- Privileged account protection
- Security Defaults status
- Conditional Access presence
- Guest user count
Email Security
Collect:
- Safe Links enabled status
- Safe Attachments enabled status
- Anti-phishing protection status
Device Evidence
Collect:
- Intune presence
- High-level device compliance indicators
Exclusions
Do NOT include:
- Access log ingestion
- User activity reporting
- Raw audit logs
- Full Secure Score dashboards
- Data Loss Prevention policies
- Retention policies
- Collaboration security settings
- External sharing analysis
- Raw Conditional Access exports
- Mailbox information
- Device inventories
- Microsoft administration functionality
Placement
MSP Portal
Add:
- Microsoft 365 Security Evidence
Suggested location:
Settings > Data & Integrations
Connection Management
The platform should allow MSP Admins to manage Microsoft connectivity.
Required actions:
- Connect Microsoft 365
- Reconnect Microsoft 365
- Disconnect Microsoft 365
- Sync Now
Display:
Status:
Connected via GDAP
Last Sync:
22 August 2026 14:02
Last Successful Sync:
22 August 2026 14:02
Actions:
- Sync Now
- Reconnect
- Disconnect
Authentication Requirements
Use:
- Microsoft Entra ID
- Microsoft Partner Center
- GDAP
Requirements:
- MSP authenticates once
- Customer tenants discovered automatically
- Delegated permissions respected
- Support consent handling
- Support permission revocation
- Support token refresh
Tenant Discovery
Requirements:
- Discover delegated customer tenants
- Respect GDAP role assignments
- Retrieve tenant information
- Maintain tenant relationship information
Tenant Mapping
Each Microsoft tenant must map to an internal client.
Mapping should use:
- Internal Client GUID
If no mapping exists:
Display:
Unmapped Microsoft Tenant Detected
Tenant:
Northbridge Logistics Ltd
Actions:
- Map Existing Client
- Create New Client
- Ignore
Do not automatically assign tenants.
Sync Behaviour
Default schedule:
Automatic synchronisation every 24 hours
Support:
- Scheduled sync
- Manual sync
Rules:
- Manual sync should not bypass throttling protections
Display:
Last Synced:
22 August 2026 14:02
Evidence Processing
Collected Microsoft evidence should be:
- Simplified
- Normalised
- Mapped into internal schema
- Posted into /v1/security-evidence
Raw Microsoft responses should not be surfaced directly.
Security Findings Integration
Evidence should support findings only.
Evidence must not determine final status automatically.
Example:
Multi-Factor Authentication
Suggested Status:
Partially Deployed
Evidence:
- MFA detected for administrator accounts
- MFA not detected for all users
Confidence:
High
Last Synced:
22 August 2026 14:02
MSP Action:
Confirm Final Status
AI Integration
AI may use Microsoft evidence as supporting context.
AI should:
- Improve Executive Summaries
- Improve recommendations
- Improve What's Changed narratives
AI must not:
- Independently determine security conclusions
- Override MSP decisions
Development Ownership & Collaboration
This project will be delivered alongside an existing development team.
The Microsoft specialist is expected to own Microsoft-specific functionality only.
Microsoft Specialist Ownership
Responsible for:
- Microsoft Entra configuration
- Microsoft Graph implementation
- Partner Center integration
- GDAP implementation
- Authentication flows
- Consent handling
- Token lifecycle management
- Delegated tenant discovery
- Evidence collection
- Evidence normalisation
- Microsoft technical documentation
Existing Development Team Ownership
Responsible for:
- Frontend implementation
- Database structure
- Existing API integration
- Security Findings integration
- Report integration
- Activity Log integration
- AI integration
- Deployment
- Testing
- UAT
Integration Approach
Microsoft functionality should operate as a modular service.
Service output:
/v1/security-evidence
Existing platform components will consume the data.
The implementation should:
- Minimise changes to existing architecture
- Avoid tightly coupling Microsoft-specific functionality to core platform logic
Security & Data Handling
Requirements:
- Minimise stored Microsoft data
- Do not store raw Microsoft responses unless required
- Store only normalised evidence
- Encrypt refresh tokens
- Encrypt sensitive credentials
- Use HTTPS/TLS
- Support key rotation
- Support permission revocation
- Support token invalidation
Error Handling
Must support:
- Retry logic
- Throttling awareness
- Token expiry handling
- Consent failures
- Permission failures
- Sync failures
- Tenant discovery failures
Provide:
- Granular technical logging
- User-friendly messages
Activity History
Record meaningful Microsoft events only:
- Microsoft connection created
- Microsoft connection removed
- Tenant mapping created
- Evidence sync completed
- Evidence sync failed
Do not record:
- Individual API calls
- Token refreshes
- Low-level system activity
Future Expansion
Architecture should support future evidence additions without redesign.
Future examples:
- Secure Score indicators
- Defender posture signals
- Identity risk signals
- Device posture signals
V1 should remain limited to the defined lightweight evidence scope.
Deliverables
Source code with clear project structure
Preferred:
- .NET
- Node.js
- Setup scripts and concise README
Requirements:
- Development environment setup in under 30 minutes
- Test harness demonstrating:
- Delegated tenant discovery
- Tenant-to-client mapping
- Evidence collection
- Evidence normalisation
- Successful evidence posting
- Technical handover documentation including:
- Graph permissions used
- Entra ID configuration
- Partner Center configuration
- GDAP requirements
- Token handling approach
- Consent handling
- Retry strategy
- Error handling approach
Acceptance Criteria
Successful execution within staging environment demonstrating:
- MSP authentication using Partner Center + GDAP
- Delegated customer tenant discovery
- Tenant mapping
- Evidence collection
- Evidence normalisation
- Successful posting to /v1/security-evidence
- Scheduled synchronisation
- No manual intervention required after initial setup
UAT Scenarios
UAT-MG-001
Scenario:
MSP connects Microsoft using GDAP
Expected Result:
Delegated customer tenants discovered successfully
UAT-MG-002
Scenario:
Tenant discovered without mapping
Expected Result:
Tenant displayed as unmapped
UAT-MG-003
Scenario:
Manual sync initiated
Expected Result:
Evidence synchronises successfully
UAT-MG-004
Scenario:
Microsoft permissions revoked
Expected Result:
Connection status changes and sync stops
UAT-MG-005
Scenario:
Graph throttling encountered
Expected Result:
Retry logic executes successfully
UAT-MG-006
Scenario:
Evidence displayed within Security Findings
Expected Result:
Suggested evidence shown correctly with MSP override available
Development Handover Requirements
The implementation must be written & documented so that an existing development team can fully maintain & extend the functionality without requiring ongoing involvement from the Microsoft specialist.
Required:
- clear code structure
- inline documentation
- setup documentation
- permission documentation
- architecture overview
- deployment instructions
- guidance for adding future evidence types