{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
        "slug": "dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement",
        "url": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/"
        },
        "title": "Separate BYOIP provisioning from public route advertisement",
        "summary": "A provisioned custom IPv4 prefix can supply attached addresses before Microsoft advertises the range.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-09-10T00:27:35+00:00",
        "modified_at": "2026-09-10T01:23:48+00:00",
        "reviewed_on": "2026-09-09",
        "reading_minutes": 2,
        "word_count": 248,
        "potentially_affected": "Unified custom IPv4 prefixes bringing a customer-owned address range to Azure public cloud.",
        "dse_recommendation": "Treat resource attachment and route commissioning as separate acceptance gates in a BYOIP migration.",
        "primary_source": {
            "name": "Create a custom IPv4 address prefix in Azure - Azure Virtual Network | Microsoft Learn",
            "url": "https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal",
            "published_on": null,
            "authority": "Microsoft Learn"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<h2>Source facts</h2>\n<p>For a unified custom IPv4 prefix, Microsoft permits child public prefixes and address attachments after provisioning. The documentation explicitly says those addresses are not yet advertised or reachable at that stage.</p>\n<p>In Azure public cloud, commissioning advertises the range through Microsoft under ASN 8075. Microsoft warns that simultaneous Internet advertisement from another location can cause routing instability or traffic loss, and recommends a maintenance period for an active-range migration. <a href=\"https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn</a>.</p>\n<h2>Applicability</h2>\n<p>Use this distinction for the Azure public-cloud unified custom-prefix workflow, after the required ownership and authorization preparation. This article is not a complete prefix-onboarding or route-authorization procedure and does not prescribe the public-cloud ASN for sovereign clouds.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends two separate sign-offs: the intended Azure resources have their planned addresses, and the routing change has been authorized and observed. Coordinate the existing advertiser, Azure operator and application owner before commissioning an active range. Keep the prior route state, approved transition sequence and recovery decision together. Do not interpret a successfully attached address as permission to move production traffic.</p>\n<h2>Verification</h2>\n<p>Record the actual prefix state and resource attachments before the change. During the approved window, observe route advertisement from appropriate external locations and test the intended application path. Preserve unsuccessful observations as well as successful ones. If resource provisioning is complete but the route transition is not, report those as separate outcomes rather than declaring the entire migration complete.</p>\n<h2>Official references</h2>\n<p><a href=\"https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn: Create a custom IPv4 address prefix in Azure</a>. Source retrieved September 9, 2026.</p>",
        "content_text": "Source facts\nFor a unified custom IPv4 prefix, Microsoft permits child public prefixes and address attachments after provisioning. The documentation explicitly says those addresses are not yet advertised or reachable at that stage.\nIn Azure public cloud, commissioning advertises the range through Microsoft under ASN 8075. Microsoft warns that simultaneous Internet advertisement from another location can cause routing instability or traffic loss, and recommends a maintenance period for an active-range migration. Microsoft Learn.\nApplicability\nUse this distinction for the Azure public-cloud unified custom-prefix workflow, after the required ownership and authorization preparation. This article is not a complete prefix-onboarding or route-authorization procedure and does not prescribe the public-cloud ASN for sovereign clouds.\nDSE recommendation\nDSE recommends two separate sign-offs: the intended Azure resources have their planned addresses, and the routing change has been authorized and observed. Coordinate the existing advertiser, Azure operator and application owner before commissioning an active range. Keep the prior route state, approved transition sequence and recovery decision together. Do not interpret a successfully attached address as permission to move production traffic.\nVerification\nRecord the actual prefix state and resource attachments before the change. During the approved window, observe route advertisement from appropriate external locations and test the intended application path. Preserve unsuccessful observations as well as successful ones. If resource provisioning is complete but the route transition is not, report those as separate outcomes rather than declaring the entire migration complete.\nOfficial references\nMicrosoft Learn: Create a custom IPv4 address prefix in Azure. Source retrieved September 9, 2026.",
        "content_markdown": "## Source facts\n\nFor a unified custom IPv4 prefix, Microsoft permits child public prefixes and address attachments after provisioning. The documentation explicitly says those addresses are not yet advertised or reachable at that stage.\n\nIn Azure public cloud, commissioning advertises the range through Microsoft under ASN 8075. Microsoft warns that simultaneous Internet advertisement from another location can cause routing instability or traffic loss, and recommends a maintenance period for an active-range migration. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal).\n\n## Applicability\n\nUse this distinction for the Azure public-cloud unified custom-prefix workflow, after the required ownership and authorization preparation. This article is not a complete prefix-onboarding or route-authorization procedure and does not prescribe the public-cloud ASN for sovereign clouds.\n\n## DSE recommendation\n\nDSE recommends two separate sign-offs: the intended Azure resources have their planned addresses, and the routing change has been authorized and observed. Coordinate the existing advertiser, Azure operator and application owner before commissioning an active range. Keep the prior route state, approved transition sequence and recovery decision together. Do not interpret a successfully attached address as permission to move production traffic.\n\n## Verification\n\nRecord the actual prefix state and resource attachments before the change. During the approved window, observe route advertisement from appropriate external locations and test the intended application path. Preserve unsuccessful observations as well as successful ones. If resource provisioning is complete but the route transition is not, report those as separate outcomes rather than declaring the entire migration complete.\n\n## Official references\n\n[Microsoft Learn: Create a custom IPv4 address prefix in Azure](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal). Source retrieved September 9, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
                "url": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-09-09"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Separate BYOIP provisioning from public route advertisement",
                        "item": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/#article",
                "identifier": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
                "url": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/",
                "headline": "Separate BYOIP provisioning from public route advertisement",
                "description": "A provisioned custom IPv4 prefix can supply attached addresses before Microsoft advertises the range.",
                "abstract": "A provisioned custom IPv4 prefix can supply attached addresses before Microsoft advertises the range.",
                "articleBody": "Source facts\nFor a unified custom IPv4 prefix, Microsoft permits child public prefixes and address attachments after provisioning. The documentation explicitly says those addresses are not yet advertised or reachable at that stage.\nIn Azure public cloud, commissioning advertises the range through Microsoft under ASN 8075. Microsoft warns that simultaneous Internet advertisement from another location can cause routing instability or traffic loss, and recommends a maintenance period for an active-range migration. Microsoft Learn.\nApplicability\nUse this distinction for the Azure public-cloud unified custom-prefix workflow, after the required ownership and authorization preparation. This article is not a complete prefix-onboarding or route-authorization procedure and does not prescribe the public-cloud ASN for sovereign clouds.\nDSE recommendation\nDSE recommends two separate sign-offs: the intended Azure resources have their planned addresses, and the routing change has been authorized and observed. Coordinate the existing advertiser, Azure operator and application owner before commissioning an active range. Keep the prior route state, approved transition sequence and recovery decision together. Do not interpret a successfully attached address as permission to move production traffic.\nVerification\nRecord the actual prefix state and resource attachments before the change. During the approved window, observe route advertisement from appropriate external locations and test the intended application path. Preserve unsuccessful observations as well as successful ones. If resource provisioning is complete but the route transition is not, report those as separate outcomes rather than declaring the entire migration complete.\nOfficial references\nMicrosoft Learn: Create a custom IPv4 address prefix in Azure. Source retrieved September 9, 2026.",
                "datePublished": "2026-09-10T00:27:35+00:00",
                "dateModified": "2026-09-10T01:23:48+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/dse-20260909-261-separate-byoip-provisioning-from-public-route-advertisement/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Separate BYOIP provisioning from public route advertisement"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 248,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "Create a custom IPv4 address prefix in Azure - Azure Virtual Network | Microsoft Learn",
                    "url": "https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal"
                }
            }
        ]
    }
}